<story><title>Git rebase, what can go wrong</title><url>https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/</url></story><parent_chain><item><author>recursive</author><text>Squash merges cut down the noise considerably.</text></item><item><author>jawns</author><text>I like how Atlassian puts it:&lt;p&gt;&amp;gt; The golden rule of rebasing&lt;p&gt;&amp;gt; Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.atlassian.com&amp;#x2F;git&amp;#x2F;tutorials&amp;#x2F;merging-vs-rebasing#the-golden-rule-of-rebasing&quot; rel=&quot;nofollow noreferrer&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.atlassian.com&amp;#x2F;git&amp;#x2F;tutorials&amp;#x2F;merging-vs-rebasing#...&lt;/a&gt;&lt;p&gt;For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commits cluttering up the commit history.</text></item></parent_chain><comment><author>dkarl</author><text>I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand.&lt;p&gt;Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature.&lt;p&gt;But since you&amp;#x27;re working on the fly with imperfect knowledge, it doesn&amp;#x27;t happen in such neat steps. Refactorings and behavior changes end up interleaved in your raw git history, so you need to do a little bit of cleanup by hand in order to present a simple story in the commit log.&lt;p&gt;Of course if you have developers that don&amp;#x27;t do that and instead merge dozens of commits that just say wip, wip, wip, lol, fml, wip, wip, lol, yolo and you can&amp;#x27;t fire them or get them to change, then squash merges ftw.</text></comment>
<story><title>Git rebase, what can go wrong</title><url>https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/</url></story><parent_chain><item><author>recursive</author><text>Squash merges cut down the noise considerably.</text></item><item><author>jawns</author><text>I like how Atlassian puts it:&lt;p&gt;&amp;gt; The golden rule of rebasing&lt;p&gt;&amp;gt; Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.atlassian.com&amp;#x2F;git&amp;#x2F;tutorials&amp;#x2F;merging-vs-rebasing#the-golden-rule-of-rebasing&quot; rel=&quot;nofollow noreferrer&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.atlassian.com&amp;#x2F;git&amp;#x2F;tutorials&amp;#x2F;merging-vs-rebasing#...&lt;/a&gt;&lt;p&gt;For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commits cluttering up the commit history.</text></item></parent_chain><comment><author>mablopoule</author><text>I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame.&lt;p&gt;I&amp;#x27;m a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I&amp;#x27;m working on, and I die a little bit each time I try to understand what changes were related to a line when tracking down a bug.</text></comment>