[iBelieve]

I like to either squash feature branches into develop/master, or squash the commits in that branch into multiple commits (for example, an unrelated fix I made, and then the main feature commit) and then do a fast-forward-only merge, so there's never merge commits from feature branches.

The reason I like doing squashes is not because I don't want a detailed history. It's because (1) it allows me to commit often, even when the code isn't fully finished, might not build or pass all the tests and (2) during code review, I might need to fix a typo, change the code, or make other changes. By squashing these commits into one feature commit, I can ensure that each commit builds and passes tests, which is very helpful when doing git bisects later. It also removes history that doesn't matter (those code review fixup commits, as well as all my work-in-progress commits), so what's left is a nice history of the project, hopefully with each commit describing in high-level detail what changed and why, as well as linking to a ticket/issue/bug report.

That also lets me only use merge commits for things that really are "merging", such as merging develop into master, where master has additional hotfix commits. I always use merge commits for that (never fast-forwarding), so it's always clear when code was merged from develop and released.

[mkiwala]

What you are describing is not what the author of the article is advocating, which is `git merge --squash`.

What you've described -- committing often and later combining commits together into cohesive units that don't break tests -- is a lot like how I work. I use `git rebase -i` for this; never `git merge --squash`.