lab 34 Rebasing

Goals

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.

Execute:

git checkout greet
git rebase master
git hist

Output:

$ 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: bonjour uses Greeter
Applying: updated Rakefile
$
$ git hist
* 5c4b651 2014-02-21 | Ajout d'un README (HEAD, master) [Jim Weirich]
* 6f69f38 2014-02-21 | Ajout d'un Rakefile [Jim Weirich]
* c8d6b61 2014-02-21 | Déplacement de bonjour.rb dans lib [Jim Weirich]
* 83558be 2014-02-21 | Add an author/email comment [Jim Weirich]
* a9c6007 2014-02-21 | Ajout d'un commentaire (v1) [Jim Weirich]
* 221243e 2014-02-21 | Ajouter une valeur par défaut (v1-beta) [Jim Weirich]
* 80fc666 2014-02-21 | Using ARGV [Jim Weirich]
* 834ca4f 2014-02-21 | Mon premier commit [Jim Weirich]

Merge VS Rebase 01

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? 02

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.

Table des matières