Explains merge strategies
Explains merge strategies

When creating branches and merging with master, there are two strategies
to doing that merge:

  1. Maintain linear commit history on master (my preference).
  2. Keep branch commit history leading to tramlines when viewing commit
     history on master.

The only difference between the two approaches is to do a

  git rebase master

prior to merging. So this is my recommended strategy:

1. git branch wip
2. git checkout wip
....work done here is done on local branch wip...
3. git rebase master
4. git checkout master
5. git merge wip
6. git branch -d wip

whereas the alternative is:

1. git branch wip
2. git checkout wip
....work done here is done on local branch wip...
3. git checkout master
4. git merge wip
5. git branch -d wip

Maintaining a linear commit history makes the project readable, besides
if commit messages are written in detail explaining what happened in the
branch then the evolution of the project is explained in the text
(commit message body) rather than visually. Both can be useful, however,
depending on the project/team requirements.

0xMF/toybox