merge vs. rebase
One of the best ways to incorporate rebasing into your workflow is to clean up local, in-progress features. By periodically performing an interactive rebase, you can make sure each commit in your feature is focused and meaningful. This lets you write your code without worrying about breaking it up into isolated commits ‐ you can fix it up after the fact.
git rebase, you have two options for the new base: The feature's parent
master), or an earlier commit in your feature. We saw an example of the
first option in the Interactive rebasing section. The latter option is nice when you
only need to fix up the last few commits. For example, the following command begins an
interactive rebase of only the last 3 commits.
git checkout feature git rebase -i HEAD~3
HEAD~3 as the new base, you're not actually moving the branch ‐
you're just interactively re-writing the 3 commits that follow it. Note that this will
not incorporate upstream changes into the 'feature' branch.
If you want to re-write the entire feature using this method, the
command can be useful to find the original base of the
feature branch. The following
returns the commit ID of the original base, which you can then pass to
git merge-base feature master
This use of interactive rebasing is a great way to introduce
git rebase into your
workflow, as it only affects local branches. The only thing other developers will see
is your finished product, which should be a clean, easy-to-follow feature branch history.
But again, this only works for private feature branches. If you're collaborating with other developers via the same feature branch, that branch is public, and you're not allowed to re-write its history.
There is no
git merge alternative for cleaning up local commits with an interactive