I don't disagree with you, but for some teams, there is merit to keeping the commit history "clean". Perhaps their workflow involves looking at the commit history often, in order to diagnose issues or find information.
Ideally, they would redesign their workflow to avoid these issues. However, sometimes we run up against deadlines that require us to fit solutions into the current workflow, rather than spending the time to train the team on a new workflow + rewrite the existing tooling to use the new workflow.
It's not an ideal solution, but it is certainly a solution. One that may actually be effective for some teams.
There is only one place where I use squash commits, and that for work on CD/CI pipelines, as a lot of these systems (e.g. Gitlab) provide no way to test before committing and pushing.
Thank you for the links, they seem very useful and I'll take a look at them tomorrow!
I guess I should clarify my original point with some context. I once worked at a company where everyone pushed directly to prod, and the primary workflow for diagnosing issues was "look at the commit history until you find the most relevant description". For some developers, having a long commit history was a major issue, because they couldn't find what they were looking for in a timely manner.
Would it have been easier for us to resolve problems with better source control management and training? Absolutely. But the majority of developers there had very little git experience, and some didn't even understand the concept of "local branches" or "pull requests". And yet, our product was successful, and was making money.
In this scenario, it was (sadly) more efficient for us to consolidate all of our changes into a single "feature commit". Changing our workflow, and teaching the new workflow to everyone at the company, simply required more overhead than was deemed worthwhile. I hated that process, and there's a reason I no longer work there, but the fact remains that the company is still successful despite poor source control practices. For companies like that, who value functionality over best practices, squashing commits can be an effective shortcut to improve their workflow.
I agree with you, that having a detailed commit history provides significant value and should always be the go-to. But some teams continue to thrive without following best practices, and articles like this can still be useful to them, even though they would be better served by improving the root issues in their workflow.
Nothing wrong with pushing directly to main line. In fact, that's what I prefer and is basically required if you want to practice Continuous Integration.
Looking at the commit history to find the most relevant description isn't really the best approach to diagnosing issues. It's the second or third step. You should locate where the problem occurs, and only then look at the history. Just because somebody changed part of the code which now causes a problem doesn't mean that this change introduced a problem, it might just uncovered a new problem.
With small and frequent ACID-style commits with proper descriptive commit messages you will be able to reason about why changes were made, and possibly the reasoning behind it. Things which get lost with a squash commit, because then you don't get information about which major thing was changed but not why the smaller parts changed. What was changed is also visible from the changed code.
With software development recording the why is more important than recording the what. Because the latter we already solved.
To summarize your and my point:
If too many commits is a problem, then you might be working wrong.
Squashing commit does not solve this problem, it just tries to hide it under a rug.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
And what exactly is the problem with that?
I think squashing commits is generally a really bad idea. You are destroying history.
I don't disagree with you, but for some teams, there is merit to keeping the commit history "clean". Perhaps their workflow involves looking at the commit history often, in order to diagnose issues or find information.
Ideally, they would redesign their workflow to avoid these issues. However, sometimes we run up against deadlines that require us to fit solutions into the current workflow, rather than spending the time to train the team on a new workflow + rewrite the existing tooling to use the new workflow.
It's not an ideal solution, but it is certainly a solution. One that may actually be effective for some teams.
Which is exactly the reason not to squash commits. Being able to dig through the smaller increments exposes a wealth of information.
A good book on this subject is Your Code as a Crime Scene and the followup Software Design X-Rays.
There is only one place where I use squash commits, and that for work on CD/CI pipelines, as a lot of these systems (e.g. Gitlab) provide no way to test before committing and pushing.
Thank you for the links, they seem very useful and I'll take a look at them tomorrow!
I guess I should clarify my original point with some context. I once worked at a company where everyone pushed directly to prod, and the primary workflow for diagnosing issues was "look at the commit history until you find the most relevant description". For some developers, having a long commit history was a major issue, because they couldn't find what they were looking for in a timely manner.
Would it have been easier for us to resolve problems with better source control management and training? Absolutely. But the majority of developers there had very little git experience, and some didn't even understand the concept of "local branches" or "pull requests". And yet, our product was successful, and was making money.
In this scenario, it was (sadly) more efficient for us to consolidate all of our changes into a single "feature commit". Changing our workflow, and teaching the new workflow to everyone at the company, simply required more overhead than was deemed worthwhile. I hated that process, and there's a reason I no longer work there, but the fact remains that the company is still successful despite poor source control practices. For companies like that, who value functionality over best practices, squashing commits can be an effective shortcut to improve their workflow.
I agree with you, that having a detailed commit history provides significant value and should always be the go-to. But some teams continue to thrive without following best practices, and articles like this can still be useful to them, even though they would be better served by improving the root issues in their workflow.
Nothing wrong with pushing directly to main line. In fact, that's what I prefer and is basically required if you want to practice Continuous Integration.
Looking at the commit history to find the most relevant description isn't really the best approach to diagnosing issues. It's the second or third step. You should locate where the problem occurs, and only then look at the history. Just because somebody changed part of the code which now causes a problem doesn't mean that this change introduced a problem, it might just uncovered a new problem.
With small and frequent ACID-style commits with proper descriptive commit messages you will be able to reason about why changes were made, and possibly the reasoning behind it. Things which get lost with a squash commit, because then you don't get information about which major thing was changed but not why the smaller parts changed. What was changed is also visible from the changed code.
With software development recording the why is more important than recording the what. Because the latter we already solved.
To summarize your and my point:
Squashing commit does not solve this problem, it just tries to hide it under a rug.