Merge can be used when you want to merge a feature branch back into your development branch. That way, you’ll be able to see when you merged in what in the future because you have that merge commit I called “nasty” before. It isn’t, really.
I've come to prefer merges for this case. It reflects reality - you really were developing on a separate history for a while, you're not interweaving bugfixes from master with feature work, etc. And it visually (and logically) groups the commits for the feature, so it's very easy to review or revert the feature as a whole, instead of having to figure out exactly which commits in the big linear history are relevant (or having to religiously tag every time you do anything interesting). The current git visualisation tools (gitk, gitg, gitx) aren't very good at displaying histories with interesting merge structures, but I confidently predict someone will release an awesome dotviz-based history visualiser soon which makes it easy to navigate forests of branches and merges.
That said, as the article describes, rebase does handle conflicts (syntactic and semantic) better than merge does. Because it rebases a commit at a time, you have to think about how the upstream change affects each change that you made in the feature branch, which means you're much less likely to resolve the conflict in a way which breaks some subtle assumption you baked into the code two weeks ago.
I've sometimes taken the approach of first rebasing my feature branch onto the latest master to resolve any conflicts, and then doing a 'merge --no-ff' to explicitly create a merge commit to get the visual history marker.
From the article:
Merge can be used when you want to merge a feature branch back into your development branch. That way, you’ll be able to see when you merged in what in the future because you have that merge commit I called “nasty” before. It isn’t, really.
I've come to prefer merges for this case. It reflects reality - you really were developing on a separate history for a while, you're not interweaving bugfixes from master with feature work, etc. And it visually (and logically) groups the commits for the feature, so it's very easy to review or revert the feature as a whole, instead of having to figure out exactly which commits in the big linear history are relevant (or having to religiously tag every time you do anything interesting). The current git visualisation tools (gitk, gitg, gitx) aren't very good at displaying histories with interesting merge structures, but I confidently predict someone will release an awesome dotviz-based history visualiser soon which makes it easy to navigate forests of branches and merges.
That said, as the article describes, rebase does handle conflicts (syntactic and semantic) better than merge does. Because it rebases a commit at a time, you have to think about how the upstream change affects each change that you made in the feature branch, which means you're much less likely to resolve the conflict in a way which breaks some subtle assumption you baked into the code two weeks ago.
I've sometimes taken the approach of first rebasing my feature branch onto the latest master to resolve any conflicts, and then doing a 'merge --no-ff' to explicitly create a merge commit to get the visual history marker.