- To use rebase instead of the merge command.
So we went back in history before the first merge and wanna relocate the changes in master to our style branch.
This time we are going to use the rebase command rather than merge.
git checkout style git rebase master git hist
$ git checkout style Switched to branch 'style' $ $ git rebase master First, rewinding head to replay your work on top of it... Applying: Added css stylesheet Applying: Hello uses style.css Applying: Updated index.html $ $ git hist * 6e6c76a 2011-03-09 | Updated index.html (HEAD, style) [Marina Pushkova] * 1436f13 2011-03-09 | Hello uses style.css [Marina Pushkova] * 59da9a7 2011-03-09 | Added css stylesheet [Marina Pushkova] * 6c0f848 2011-03-09 | Added README (master) [Marina Pushkova] * 8029c07 2011-03-09 | Added index.html. [Marina Pushkova] * 567948a 2011-03-09 | Moved hello.html to lib [Marina Pushkova] * 6a78635 2011-03-09 | Add an author/email comment [Marina Pushkova] * fa3c141 2011-03-09 | Added HTML header (v1) [Marina Pushkova] * 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Marina Pushkova] * 43628f7 2011-03-09 | Added h1 tag [Marina Pushkova] * 911e8c9 2011-03-09 | First Commit [Marina Pushkova]
01 Merging VS rebasing
Result of the rebase command looks much like that of the merge. The style branch currently contains all its changes, plus all the changes of the master branch. The commit tree, however, is a bit different. The style branch commit tree has been rewritten to make the master branch a part of the commit history. This makes the chain of commits linear and more readable.
02 When to use the rebase, when the merge?
Don’t use the rebase command …
- If the branch is public and shared. Rewriting such branches will hinder the work of other team members.
- When the exact commit branch history is important (because the rebase command rewrites the history of commits).
Given the above recommendations, I prefer to use rebase for short-term, local branches and the merge command for branches in the public repository.