Setup repository with a master branch and a dev branch. dev should be made the default branch.

All development should be worked on in respective branches and merged into dev. See branch naming and merging guidelines below.

Master should contain the most recent published/released copy. See merging guidelines below.

category/master

category/github_username/short_description

• category examples: sample_code, guidebook

  • keep this consistent within a project

  • each category should have its own master branch

• short_description should explain what github_username is working on in that branch

Creating a pull request

Merging a pull request

1. Pull request: select merge pull request option

2. Via command line: Using merge will maintain the true history of the development work.

git checkout category/github_username/short_description

git merge category/master

1. Pull request: select squash and merge option

2. Via command line: Using rebase will maintain a linear timeline for clarity. Squash new commits into one during the interactive rebase.

git checkout category/master

git rebase -i dev

Merging dev into master

1. Pull request: select merge pull request option

2. Via command line:

git checkout dev

git merge master

Proposing changes to your work with pull requests

Git commit messages should be thought out and not rushed. This message provides other users with a way to understand what changes you made in your commit.

A proper git commit message should follow a standard format.

The standard commit message is as follows:

type(category): subject — footer for example: feat(guidebook): added title-page

• feat — A new feature.

• fix — A bug fix.

• docs — Changes to only documentation.

• style — Changes to formatting (missing semicolons, etc.).

• refactor — A code change that neither fixes a bug nor adds a feature.

• test — Adding missing or correcting existing tests.

• chore — Change to build process or auxiliary tools, or maintenance.

This should correspond with the branch names.

The subject should be limited to 50 characters and be descriptive of the changes. If there are multiple things changed, consider splitting into smaller commits (use git add -p).

Git Workflow Etiquette - Better Programming

git add -p                 # stage only some changes within file(s)

git rebase -i HEAD~n       # can be used to squash last n commits

git reset --soft HEAD^     # undoes the last commit and saves stage

git stash, git stash pop   # temporarily saves local changes