lab 31 Rebasing

Goals

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 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:

$ git checkout 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
$
$ git hist
* d81bcbf 2023-08-21 | Hello uses Greeter (HEAD -> greet) [Théophile Chevalier]
* c004268 2023-08-21 | Add greeter class [Théophile Chevalier]
* 6179ba3 2023-08-21 | Added README (main) [Théophile Chevalier]
* 9ab61ca 2023-08-21 | Moved hello.py to lib [Théophile Chevalier]
* 7abea37 2023-08-21 | Add an author/email comment [Théophile Chevalier]
* 1c410c6 2023-08-21 | Add a comment (tag: v1) [Théophile Chevalier]
* 0bf384c 2023-08-21 | Display user input (tag: v1-beta) [Théophile Chevalier]
* 31c3945 2023-08-21 | Add some content [Théophile Chevalier]
* aa5d425 2023-08-21 | First Commit [Théophile Chevalier]

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 …

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.