Git Immersion

lab 32 Rebasing

Goals

Ok, we are back in time before the first merge and we want to get the changes in main into our greet branch.

This time we will use the rebase command instead of the merge command to bring in the changes from the main branch.

Execute:

git checkout greet
git rebase main
git hist

Output:

$ go greet
Switched to branch 'greet'
$
$ git rebase main
First, rewinding head to replay your work on top of it...
Applying: added Greeter class
Applying: hello uses Greeter
Applying: updated Rakefile
$
$ git hist
* c6d9ed3 2019-06-27 | Updated package (HEAD -> greet) [Halle Bot]
* 56af19d 2019-06-27 | Hello uses Greeter [Halle Bot]
* 1e7679d 2019-06-27 | Added greeter class [Halle Bot]
* 3aa3064 2019-06-27 | Added README (main) [Halle Bot]
* 2b04803 2019-06-27 | Added a package.json. [Halle Bot]
* b65b430 2019-06-27 | Moved hello.js to lib [Halle Bot]
* 4535421 2019-06-27 | Add an author/email comment [Halle Bot]
* 59992ce 2019-06-27 | Added a comment (tag: v1) [Halle Bot]
* 20a6c79 2019-06-27 | Added a default value (tag: v1-beta) [Halle Bot]
* 6915d41 2019-06-27 | Using process.argv [Halle Bot]
* 284070d 2019-06-27 | First Commit [Halle Bot]

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 main branch. However, the commit tree is quite different. The commit tree for the greet branch has been rewritten so that the main 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 …

  1. If the branch is public and shared with others. Rewriting publicly shared branches will tend to screw up other members of the team.
  2. 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.