I think local commits are pretty useful, and local branches sometimes are as well. But "using branches heavily" is a pet peeve of mine. Git encourages lots of branching that in most cases is unnecessary (e.g. making feature branches for everything, never committing directly into master). When working with a team, everybody should be working on as close to the same codebase as possible, to prevent difficult merges later on. In my view, merging has a very non-linear cost based on how far apart the branches are, both in terms of time and amount of code changed, because it's more likely that the merge will have more tangled dependencies, and the code will be less fresh in the mind of whoever's merging.
Merge commits can also hide lots of information, like exactly how any merge conflicts were resolved, since they're buried in what is basically a squashed commit of everything in the merged branch since it diverged.
And finally, they make the commit history much harder to understand. I had to bug everyone on my team to run "git config --global pull.rebase true" just to have a somewhat sane, linear history without tons of merges in day-to-day development.
When working with a team, everybody should be working on as close to the same codebase as possible, to prevent difficult merges later on.
I agree with this, but disagree that avoiding branching is a good way to do it. In my experience, the solution is more, smaller, feature-specific branches that get merged back to master quickly (within a couple of days if possible). If you need to maintain a long-running feature branch, it should frequently be rebased on top of master so that at any given point the likelihood of major conflicts is reduced.
Comments
I think local commits are pretty useful, and local branches sometimes are as well. But "using branches heavily" is a pet peeve of mine. Git encourages lots of branching that in most cases is unnecessary (e.g. making feature branches for everything, never committing directly into master). When working with a team, everybody should be working on as close to the same codebase as possible, to prevent difficult merges later on. In my view, merging has a very non-linear cost based on how far apart the branches are, both in terms of time and amount of code changed, because it's more likely that the merge will have more tangled dependencies, and the code will be less fresh in the mind of whoever's merging.
Merge commits can also hide lots of information, like exactly how any merge conflicts were resolved, since they're buried in what is basically a squashed commit of everything in the merged branch since it diverged.
And finally, they make the commit history much harder to understand. I had to bug everyone on my team to run "git config --global pull.rebase true" just to have a somewhat sane, linear history without tons of merges in day-to-day development.
I agree with this, but disagree that avoiding branching is a good way to do it. In my experience, the solution is more, smaller, feature-specific branches that get merged back to master quickly (within a couple of days if possible). If you need to maintain a long-running feature branch, it should frequently be rebased on top of master so that at any given point the likelihood of major conflicts is reduced.