Here it is a practical recipe to make you prefer rebase merging (git rebase) over recursive merging (git merge) especially when it's time to integrate changes from others while working on a feature branch.
Following alias will come in handy:
git config --local alias.history 'log --oneline --decorate --graph'
Firstly, synchronize your local repository history with the remote origin history by pulling down (fetch + merge) the master branch.
git checkout master
git fetch origin
git merge origin/master
git history -2
You might have to resolve some conflicts. When done, you local repository history will look like:
HEAD
master
v
(A) <-- (B)
^
origin/master
Make sure your HEAD is on a good commit (it builds and all tests pass!), then branch off your feature.
git branch feature
git checkout feature
git history -2
Git creates a new feature pointer and it switches HEAD to it.
HEAD
feature
master
v
(A) <-- (B)
^
origin/master
Implement the new feature by applying repeated cycles of edit, add and commit actions.
edit some/of/your/file.scala
git add some
git commit -m "Does something cool"
Please take care of commit messages as explained in the following excellent article:
http://chris.beams.io/posts/git-commit/
Git adds new nodes (C and D) to your local history and moves both the feature pointer and HEAD forward.
HEAD
master feature
v v
(A) <-- (B) <-- (C) <-- (D)
^
origin/master
If you feel your have been working to many hours in isolation then you could have missed important changes from others. To understand it, do fetch from remote origin but do not merge anything yet. In other words DO NOT pull but fetch instead!
git fetch origin
You might get additional nodes (E and F) and your origin/master pointer could move forward along a diverging path. If that happens it certainly means it's time to integrate those additional changes into yours ... but how? Enter the REBASE!
HEAD
master feature
v v
(A) <-- (B) <-- (C) <-- (D)
\
\
(E) <-- (F)
^
origin/master
A nice way to integrate changes you fetched from origin (E and F) with your local changes (C and D) is interactively rebasing your feature branch onto origin/master.
git rebase -i origin/master
TBD
Git rewrites your local history creating new nodes (C' and D') and making your feature branch appear as if it were branched off from origin/master (a later point in history).
master
v
(A) <-- (B) <-- (C) <-- (D) HEAD
\ feature
\ v
(E) <-- (F) <-- (C') <-- (D')
^
origin/master
DANGER: Though is fine rebasing local (not pushed yet) nodes, never ever rebase nodes that has been already pushed to origin! Read https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing to better understand the perils.
If you feel you've done with your feature then push to origin.
git push origin feature
master
v
(A) <-- (B) <-- (C) <-- (D) HEAD
\ feature
\ v
(E) <-- (F) <-- (C') <-- (D')
^ ^
origin/master origin/feature
Git uploads your rebased nodes (C' and D') to the remote origin and create your origin/feature pointer accordingly.
People in charge to close a code review have to integrate the approved feature branch acting on the origin repository. They should NOT rebase, but rather prefer a recursive merge (git merge) to make the feature branch clearly appear in history as a diverged short-lived branch.
ssh user@origin
cd project
git checkout master
git merge feature