Rebase your feature branches

Regularly, but at least before merging your feature branches, rebase them to get rid of "fix typo" and "wip" commits.

Getting rid of unnecessary commits

Let's say you do a git rebase -i HEAD~~~~ and have this commit history:

Copypick 1d1e1f My Feature
pick 2d2e2f My Feature - wip
pick 3d3e3f My Feature - fix typo
pick 4d4e4f My Other feature

Change it to use fixup for those commits that should be merged into the one before it:

Copypick 1d1e1f My Feature
fixup 2d2e2f My Feature - wip
fixup 3d3e3f My Feature - fix typo
pick 4d4e4f My Other Feature

You will end up with this commit history:

CopyMy Feature
My Other Feature

Much nicer! This is something that you can happily merge into master.

Rebasing on the master branch

Instead of constantly merging in master and having lots of "Merge master ..." commits around, you can rebase from time to time.

This puts your commits on top of the latest master state, offering a clearer history as your changes are in one sequence.

Run the following command (to modify your commit order before rebasing, add the -i switch if you like):

Copygit rebase origin/master

This will apply the diffs from your commits step by step.

If git runs into a conflict, you will be notified and need to resolve it. Compared to merging master, the benefit here is that you see only the changes from the commit that is now causing the conflict -- which can make resolving the conflict easier (because it is one step only).

The resolved "conflict" will be part of the commit, there won't be a merge commit as you are replaying your own commits.

Notes

• If you rebased something that was already pushed to GitHub, you then need to force-push your branch. Be careful when doing that! When you have other developers working on that branch, make sure they know you are doing a forced push and that they do a hard reset to the new state.
• If your feature branch was already merged into another branch (e.g. a staging branch), you will be applying all commits again and probably run into some conflicts. You need to be fine with that or freshly branch off the target branch (from master) so that it does not know of your old commits.
• You don't need to use git rebase, if it makes your head explode. You can use git reset as well.
• The file that opens when rebasing defines all commits that are applied, meaning:
  • Order is significant.
  • Commits are processed step by step, from top to bottom of the file.
  • If you want your commits to appear in a different order, simply reorder the lines to your liking.
  • If you delete a line, that commit will not be applied.