<story><title>Fortunately, I don&apos;t squash my commits</title><url>https://blog.ploeh.dk/2020/10/05/fortunately-i-dont-squash-my-commits/</url></story><parent_chain><item><author>davewritescode</author><text>The reason to squash commits is more than just keeping your commit history read-able, it&amp;#x27;s about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues.&lt;p&gt;If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I&amp;#x27;m a simple git revert away from fixing the issue.  If I had spread that endpoint across 25 commits, I&amp;#x27;d have to actually debug the issue in QA and figure out what I broke.  Reverting quickly lets me debug the issue on my time instead of keeping our test suite broken.&lt;p&gt;It&amp;#x27;s not always feasible, and I try not to be a stickler when people on my team don&amp;#x27;t do it but the fact is, if you&amp;#x27;re working in a world when you&amp;#x27;re delivery code quickly into real environments, having a back-out strategy is paramount.</text></item></parent_chain><comment><author>alxmng</author><text>Programmers can have the best of both worlds. Use granular commits on a local branch and squash merge into shared branches.&lt;p&gt;That way one gets clean shared history while preserving local work history.</text></comment>
<story><title>Fortunately, I don&apos;t squash my commits</title><url>https://blog.ploeh.dk/2020/10/05/fortunately-i-dont-squash-my-commits/</url></story><parent_chain><item><author>davewritescode</author><text>The reason to squash commits is more than just keeping your commit history read-able, it&amp;#x27;s about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues.&lt;p&gt;If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I&amp;#x27;m a simple git revert away from fixing the issue.  If I had spread that endpoint across 25 commits, I&amp;#x27;d have to actually debug the issue in QA and figure out what I broke.  Reverting quickly lets me debug the issue on my time instead of keeping our test suite broken.&lt;p&gt;It&amp;#x27;s not always feasible, and I try not to be a stickler when people on my team don&amp;#x27;t do it but the fact is, if you&amp;#x27;re working in a world when you&amp;#x27;re delivery code quickly into real environments, having a back-out strategy is paramount.</text></item></parent_chain><comment><author>matheusmoreira</author><text>A merge commit works just like a squashed commit except it keeps all history. This is precisely why it&amp;#x27;s sensible to avoid fast-forwarding since that operation discards the fact that a branch existed in the first place.&lt;p&gt;It&amp;#x27;s better to always have merge commits. They can be reverted just as easily. I don&amp;#x27;t understand why merge commits aren&amp;#x27;t the default in git.</text></comment>