Rebase your feature branches
Regularly, but at least before merging your feature branches, rebase them to get rid of "fix typo" and "wip" commits.
Let's say you do a
git rebase -i HEAD~~~~ and have this commit history:
pick 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:
pick 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:
My Feature My Other Feature
Much nicer! This is something that you can happily merge into master.
Rebasing on the
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):
git 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.
- 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 resetas 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.