[DougWebb]

Rebase is absolutely a part of my everyday workflow, and the rest of my team's workflow as well. (Yesterday I had to show our CTO how to use it, because the rest of the team was getting annoyed by his merge commits.)

Our workflow is:

- locally, commit to local master or a local branch

- occasionally checkout local master (if necessary) and pull using the 'rebase after fetch' option.

- if we had local master commits, fixup any conflicts in our code

- if we were working on a local branch, checkout that branch and rebase it on the new master, fixing any conflicts that arise

- If our work is complete, possibly do a final rebase to reorder and squash local commits, and fast-forward merge to master if we were on a branch. Finally, push the local master to share our work.

Note that we never rebase anything that's been pushed. Also, if we're worried that a rebase is potentially complex and error prone, we create a new branch at the existing HEAD so that the old commits don't get lost in the reflog. Once the rebase is done, we can delete that branch so the old commits can be garbage collected.

[pjc50]

Merge commits on pull are an annoying misfeature of the default workflow, but I thought you could fast-forward on pull to eliminate them?

[dangerlibrary]

> annoyed by his merge commits

Getting rid of merge commits is literally the only benefit of your workflow over the standard branching model.

[DougWebb]

Not true. We've also found that rebasing our own work onto the latest master makes it a lot easier to deal with conflicts. When you do a merge, the conflicts you see are a mixture of your own code and someone else's code, and it can be hard to tell which is correct because you're not familiar with the other person's changes. But when you rebases, all of the changes are code that you wrote, so it's easier to figure out how to fix the conflict.

This may sound counter-intuitive, because you're thinking it's the same conflict either way. Most of the time it is; if you and someone else changed the same bit of code, the conflict will be shown to you the same way whether you merge or rebase. Those are easy to fix. What's harder is when someone reorganizes some code without making significant changes to it. In a merge, you'll see changes all over the place, but in a rebase git can usually figure out the new line numbers, and may not indicate a conflict at all. The other area where my team has had difficulty with merges is in Visual Studio sln and csproj files. When you add new projects to a solution or new references to a project, git can present a very confusing diff during a merge conflict. But for rebase only your additions are highlighted, and most of the time you can solve the conflict with "use theirs before mine".