lab 34 Rebasing
- Use the rebase command rather than the merge command.
Ok, we are back in time before the first merge and we want to get the changes in master into our greet branch.
This time we will use the rebase command instead of the merge command to bring in the changes from the master branch.
git checkout greet git rebase master git hist
$ go greet Switched to branch 'greet' $ $ git rebase master First, rewinding head to replay your work on top of it... Applying: added Greeter class Applying: hello uses Greeter Applying: updated Rakefile $ $ git hist * c46c56e 2018-09-28 | Updated Rakefile (HEAD -> greet) [Jim Weirich] * 0ccac93 2018-09-28 | Hello uses Greeter [Jim Weirich] * a5ff572 2018-09-28 | Added greeter class [Jim Weirich] * 5c40874 2018-09-28 | Added README (master) [Jim Weirich] * 191f0c6 2018-09-28 | Added a Rakefile. [Jim Weirich] * ef98cae 2018-09-28 | Moved hello.rb to lib [Jim Weirich] * e1e08fd 2018-09-28 | Add an author/email comment [Jim Weirich] * 7bf0bf1 2018-09-28 | Added a comment (tag: v1) [Jim Weirich] * 9cf3f21 2018-09-28 | Added a default value (tag: v1-beta) [Jim Weirich] * 94e1b8b 2018-09-28 | Using ARGV [Jim Weirich] * f656098 2018-09-28 | First Commit [Jim Weirich]
Merge VS Rebase
The final result of the rebase is very similar to the merge. The greet branch now contains all of its changes, as well as all the changes from the master branch. However, the commit tree is quite different. The commit tree for the greet branch has been rewritten so that the master branch is a part of the commit history. This leaves the chain of commits linear and much easier to read.
When to Rebase, When to Merge?
Don’t use rebase …
- If the branch is public and shared with others. Rewriting publicly shared branches will tend to screw up other members of the team.
- When the exact history of the commit branch is important (since rebase rewrites the commit history).
Given the above guidelines, I tend to use rebase for short-lived, local branches and merge for branches in the public repository.