Menu
Both approach seem to have the same purpose to have clean history:
Git Rebase
No fast forward (--no-ff)
So, if I have done rebasing on a feature branch, do I still need --no-ff when merging back to the main branch?
UPDATE:
It seems to me there is a confusion between rebasing, fast forward and non fast forward merging, basically diagram (fig 3.28) in this link http://git-scm.com/book/en/Git-Branching-Rebasing shows normal merge result is the same as merge --no-ff from the top answer of this link Why does git fast-forward merges by default?
475
The Git merge --no-ff command merges the specified branch into the command in the current branch and ensures performing a merge commit even when it is a fast-forward merge. It helps in record-keeping of all performed merge commands in the concerning git repo.
Rebase and Fast-Forward Merge You have added 2 commits to your feature branch and by the time you want to merge it back to master, your colleagues have added 4 commits to it. In this situation, we say the feature branch is 2 commits ahead of the master and 4 commits behind.
A fast-forward merge can occur when there is a linear path from the current branch tip to the target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast forward”) the current branch tip up to the target branch tip.
With --ff , when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit).
It depends how you want your history to look.
A really simple example:
* 33ad16c (HEAD, master) Merge branch 'feature-1' |\ | * e61c6a6 Various bug fixes | * e15a356 Started feature |/ * 38b8ada Initial commit * e61c6a6 (HEAD, master) Various bug fixes * e15a356 Started feature * 38b8ada Initial commit These two histories reflect the exact same commits but using the --no-ff, the first history makes it really clear how 2 of the commits where, in fact, part of the same set of work. This allows you to know exactly what work went into what feature. This makes it easier to roll back changes or just give yourself context when navigating the history.
The rebase history does not show this distinction and it makes it impossible to see any grouping of work. It makes it look like everyone is committing to master.
The empty merge commit you get with --no-ff also gives a helpful place to hang a commit message, whereas a plain commit gives you no easy place to say "This commit merges in the work for feature-x", which again is helpful for history
153
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
