Merge commits have multiple parents which makes visual inspection confusing, and it makes it much harder to use git bisect which is a tool that can save many hours of painstaking manual work.
I clearly think that the rebase version is the correct approach, but I can see there are upsides and downsides for both. Sometimes for long lived branches I get merge commits in my feature / bugfix branches, but those are going to end up squash merged onto our release branch, so in the end the main thing I care about is the linearity of history in master/develop.
Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). A merge based approach shows you what people were actually doing though.
https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
> Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality).
I still haven't heard a good reason why linear history using git as an archaeological tool is the appropriate method to "infer intent". It seems like you would only have to infer intent this way if you have poor development practices, like not adding appropriate comments and not tying important changes to tickets that provide more background/context.
Rewriting history when things land in develop/master I think is a good thing. To use an analogy from the humanities, history is written by the winner.
At work we're collaborating with the merge camp at the moment and it's very difficult to work out what they're doing from reading their history - some of it is their bad practices elsewhere, but the merge commits are confusing.
I'd also be fine with no rebasing but any merges must be fast forward, so if you can't do that fix your problems prior to integration.
Also I've used a few different approaches for a few different projects, and the rebase/squash merge approach is the one that in my experience makes things clearer and easier to understand. I'd be reluctant to return to other approaches (aside from enforcing fast forward merges in public branches).
I believe that squash merges are a good compromise as so long as you don't mess with the reflog and keep the automated parts of the commit messages, then there is no lying about history.
I think the Fossil devs also make a good case that the problem is really a limitation in the tools like git bisect.
That makes no sense. What does it matter that interim versions from a merge might not work, what matters are the milestones like merges and tags. Basically you're imposing a silly aesthetic restriction on what's supposed to be a functional tool.
I try to do this as I go, but there is always a "history review and fix if necessary" stage after I've got the code I wanted and before merging.
Apart from having granular, reviewable, bisectable history, there were many a time when by having this extra look at the code I found bugs or design flaws.
Whether such effort is worth it for you, and whether you have time\energy\discipline\skills for it is a different question.
If your feature branches have independently working commits, go ahead and branch. Most people’s feature branches are developer diaries instead of potentially releasable products. Merging them would make everyone’s lives worse, so of course they get squashed.
Rebases are a bit weird since they mostly help during bisecting but still require production-ready commits in feature branches.
I agree that some feature branches can be developer diaries, but I'm not sure why throwing away the diary is a good thing, and why the repo should only contain "releasable products". Sounds like an aesthetic preference rather than something concrete.
This is your chance to learn about git bisect.
I make a point of requiring that anyway. You gotta learn to build incrementally, repeatedly landing squashed mega-commits into main is just a recipe for future pain. To level up as a software developer, learn to create incremental work. git rebase -i is your friend.
It boggles my mind that people think 1) rebase makes more sense than branching and merging, and 2) that someone would use rebase so much that they forget how to branch and merge.