Git workflow

Goals

• Develop without fear
• Maintain a coherent commit history

Principles

1. Commit early and often. By committing as soon as your unit-tests pass, you establish a baseline to which you can return in case the next step in development crashes and burns. The baseline gives you freedom to explore and try new approaches, without worrying about destroying working code. Frequent commits also makes it easier to determine which code change introduced a bug (see git bisect).
2. Maintain a deployable master branch. Being able to checkout the latest version of the code and get a working system is a good thing.
3. Develop on a branch (usually a local branch). Separating your in-progress development helps to keep the master branch clean and makes it easier to work on different features concurrently.
4. Use rebase rather than pull or merge. Rebase will insert any new code from the repository into your local copy and then apply your changes. Using rebase ensures that all your commits stay grouped together, making the git commit history easier to comprehend. Using merge may intermingle commits from different developers, making the history less understandable. While developing, fetch and rebase frequently, to minimize the difference between your development branch and master.
5. When ready to push your changes to the repository, merge the development branch with the local master, and then push the code.

Examples

Simple workflow

git pull --rebase               # Get latest version and move any of your changes on top
(edit)                          # Make your changes
git commit                      # Save your changes
git pull --rebase               # Get latest version and move any of your changes on top
git push                        # Share and enjoy

Working on a branch (required if you're going to submit a pull request)

git checkout -b branchname      # Create and checkout a new branch named 'branchname'
git fetch origin                # Get the latest version from the repository
git rebase origin/master        # Pull in the latest code and apply your changes on top
git checkout master             # Switch to your local master branch
git merge branchname            # Merge in your local changes
git push                        # Share and enjoy

Working on two things at once

git checkout -b feature         # Create a branch for developing a feature
git checkout -b bugfix          # You decide to work on an emergency bug fix
git checkout master             # Once the bug fix is complete
git merge bugfix                # you merge in your changes
git push                        # and push them to github
git checkout feature            # Continue with feature development
git rebase master               # but first move in your bugfix changes in the branch.

New changes after merge

It is possible that new changes are pushed to the repository after you merge but before you push. In this case, rebase your changes again, from the main branch:

git fetch origin                # Get the new changes
git rebase origin/master        # Apply your changes
git push                        # Try to push again

If the push keeps failing, try to coordinate with the other developer.

Rebase merge conflict

Conflicts may appear when the rebase is applying your changes. In contrast to merge, the conflicts will be reported for each individual commit. Fix the conflict, and then continue the rebase with

git rebase --continue           # Apply the next commit

Sometimes, the conflict resolution may mean that your current changes are not needed. If so:

git rebase --skip               # Skip the next patch

In case of emergency:

git rebase --abort              # Return to state before rebase