[mkiwala]

I don't think I will ever understand people's fascination with squashing feature branches.

Develop on a branch, yes; rebase the branch instead of merging in master, sure. But why delete the history by squashing, when a merge into the mainline can look just as neat without requiring history to be deleted.

The argument that I've heard is "so that I don't have to all of that detailed history." But that is a display problem, not an argument for removing history.

[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`.

[jrhurst]

I don't think I'd ever done a full branch squash. However I have done small `rebase -i` squashes where I put together small commits that were related. At the point of where I am rebasing something into master I'd prefer fewer commits. However, it really adds no value to my git commit history other than it makes me feel better about it. I get no complaints from my coworkers in these scenarios.

[mkiwala]

I think my way of working is not too dissimilar from yours. I definitely use plenty of `rebase -i` in my workflow.