<story><title>Extremely Linear Git History</title><url>https://westling.dev/b/extremely-linear-git</url></story><parent_chain><item><author>infogulch</author><text>Github-style rebase-only PRs have revealed the best compromise between &amp;#x27;preserve history&amp;#x27; and &amp;#x27;linear history&amp;#x27; strategies:&lt;p&gt;All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you&amp;#x27;ve tested each commit independently), otherwise squash.&lt;p&gt;If you want more detail about the development of the PR than the merge commit, aka the &amp;#x27;real history&amp;#x27;, then open up the PR and browse through Updates, which include commits that were force-pushed to the branch and also fast-forward commits that were appended to the branch. You also get discussion context and intermediate build statuses etc. To represent this convention within native git, maybe tag each Update with pr&amp;#x2F;123&amp;#x2F;update-N.&lt;p&gt;The funny thing about this design is that it&amp;#x27;s actually more similar to the kernel development workflow (emailing crafted patches around until they are accepted) than BOTH of the typical hard-line stances taken by most people with a strong opinion about how to maintain git history (only merge&amp;#x2F;only rebase).</text></item></parent_chain><comment><author>couchand</author><text>What&amp;#x27;s weird about most of these discussions is how they&amp;#x27;re always seen as technical considerations distinct from the individuals who actually use the system.&lt;p&gt;The kernel needs a highly-distributed workflow because it&amp;#x27;s a huge organization of loosely-coupled sub-organizations.  Most commercial software is developed by a relatively small group of highly-cohesive individuals.  The forces that make a solution work well in one environment don&amp;#x27;t necessarily apply elsewhere.</text></comment>
<story><title>Extremely Linear Git History</title><url>https://westling.dev/b/extremely-linear-git</url></story><parent_chain><item><author>infogulch</author><text>Github-style rebase-only PRs have revealed the best compromise between &amp;#x27;preserve history&amp;#x27; and &amp;#x27;linear history&amp;#x27; strategies:&lt;p&gt;All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you&amp;#x27;ve tested each commit independently), otherwise squash.&lt;p&gt;If you want more detail about the development of the PR than the merge commit, aka the &amp;#x27;real history&amp;#x27;, then open up the PR and browse through Updates, which include commits that were force-pushed to the branch and also fast-forward commits that were appended to the branch. You also get discussion context and intermediate build statuses etc. To represent this convention within native git, maybe tag each Update with pr&amp;#x2F;123&amp;#x2F;update-N.&lt;p&gt;The funny thing about this design is that it&amp;#x27;s actually more similar to the kernel development workflow (emailing crafted patches around until they are accepted) than BOTH of the typical hard-line stances taken by most people with a strong opinion about how to maintain git history (only merge&amp;#x2F;only rebase).</text></item></parent_chain><comment><author>pnt12</author><text>I wholeheartedly agree!&lt;p&gt;With this, you can also push people towards smaller PRs which are easier to review and integrate.&lt;p&gt;The downside is that if you és o work on feature 2 based on feature 1,either you wait for the PR to be merged in main (easiest approach) or you fork from your feature branch directly and will need to rebase later (this can get messier, especially if you need to fix errors in feature 1).</text></comment>