This misses using `git pull --rebase` [1] (or even better: `git config --global pull.rebase true`), which greatly simplifies things working with others, and avoids tons of extra merge commits. It also doesn't have the downside of rewriting remote history like a straight `git rebase` can.
> With "pure merge" strategies (without rebasing regularly, as suggested above), the history in the master branch will be interspersed with the commits from all the features being developed concurrently. Such a mixed-up history is harder to review. The exact commit times are usually not that important. It's better to have a history that's easier to review.
This seems to be a common sentiment. I don't get it, but maybe someone can explain what I'm missing?
I am a strong advocate of using pull requests to merge to master, and merging them using `--no-ff`. Each PR has a merge commit on master.
If you've ever worked on a feature branch (and have a local copy of it in your repository) it's simple to see when it's safe to delete, because you can literally trace it making its way into master (or a hotfix branch, if relevant). When you do squash or rebase merges, this feature goes away.
With any even moderately-sized feature (tens or more of commits, eg, a few days' work or more), the individual commits can sometimes contain value later. Doing a git blame months later, it's occasionally useful to diagnose why something is done a certain way. Squash merges lose this detail.
What do you get for all these tradeoffs that affect daily work -- a "clean history" on master? Wtf?
I'd rather look a list of tickets, merged PRs, or the release notes to see what's changed. If I really want to look at it in git I can do `git log --merges --oneline`.
The only time I ever scroll back through the tree looking at the actual graph is when I'm trying to figure out why some branch did or did not get merged somewhere, and this feature is compromised with rebase merges, and doesn't even exist with squash merges!
Squash merge (and to a lesser extent, rebase merge) make a bunch of useful things harder or impossible, and the only benefit I see is superficial and one I never use. Am I alone in this? I feel like I'm taking crazy pills every time I see advocacy for a squash merge strategy.
(I'll leave fast-forward merge out: That keeps the "messy" history that squash advocates apparently don't like, but also makes the lineage of a feature branch confusing as a ff merge looks like work was just done on master directly. My probably naive assumption is that no one ever uses ff merge on master.)
> With "pure merge" strategies (without rebasing regularly, as suggested above), the history in the master branch will be interspersed with the commits from all the features being developed concurrently. Such a mixed-up history is harder to review. The exact commit times are usually not that important. It's better to have a history that's easier to review.
This seems to be a common sentiment. I don't get it, but maybe someone can explain what I'm missing?
I am a strong advocate of using pull requests to merge to master, and merging them using `--no-ff`. Each PR has a merge commit on master.
If you've ever worked on a feature branch (and have a local copy of it in your repository) it's simple to see when it's safe to delete, because you can literally trace it making its way into master (or a hotfix branch, if relevant). When you do squash or rebase merges, this feature goes away.
With any even moderately-sized feature (tens or more of commits, eg, a few days' work or more), the individual commits can sometimes contain value later. Doing a git blame months later, it's occasionally useful to diagnose why something is done a certain way. Squash merges lose this detail.
What do you get for all these tradeoffs that affect daily work -- a "clean history" on master? Wtf?
I'd rather look a list of tickets, merged PRs, or the release notes to see what's changed. If I really want to look at it in git I can do `git log --merges --oneline`.
The only time I ever scroll back through the tree looking at the actual graph is when I'm trying to figure out why some branch did or did not get merged somewhere, and this feature is compromised with rebase merges, and doesn't even exist with squash merges!
Squash merge (and to a lesser extent, rebase merge) make a bunch of useful things harder or impossible, and the only benefit I see is superficial and one I never use. Am I alone in this? I feel like I'm taking crazy pills every time I see advocacy for a squash merge strategy.
(I'll leave fast-forward merge out: That keeps the "messy" history that squash advocates apparently don't like, but also makes the lineage of a feature branch confusing as a ff merge looks like work was just done on master directly. My probably naive assumption is that no one ever uses ff merge on master.)
[1] https://coderwall.com/p/7aymfa/please-oh-please-use-git-pull...