在 GitHub 上维护线性历史记录，同时拥有 2 个永久分支

Posted 2023-02-19

【中文标题】在 GitHub 上维护线性历史记录，同时拥有 2 个永久分支

【英文标题】：Maintaining linear history on GitHub while having 2 permanent branches

【发布时间】：2021-10-13 00:26:15

【问题描述】：

我在 GitHub 上有一个公司 git 存储库，有 10 名开发人员全职工作，过去到处都在进行合并，功能分支是基于的，并且进入开发和修补程序分支是基于并进入main，但确保始终将修补程序合并回develop是一个真正的PITA，并导致提交多次出现在历史记录中，并且一碗真正的意大利面试图阅读gitlog，所以我正在尝试对其强制执行线性历史记录。

我打算花一点时间考虑两个分支相等来做到这一点。 （通过在大部署后删除当前开发并从主创建新的开发分支），关闭合并提交（存储库中只允许 squash 和 rebase）并最好强制执行线性历史记录。

功能分支应从开发中分支出来，每天从开发中重新建立基础以保持最新状态，并且在功能完成后应将其压缩回开发中。 同样，修补程序应该从 main 分支出来，每天从 main 重新定位（不应该需要，因为修补程序应该很快）以保持最新状态，当修补程序完成后，它应该被压缩回 main。李>

为了确保修补程序进入开发并仍然具有线性历史，我打算在每个修补程序之后将 development 重新定位到 main 上，但这是否违反了重新定位的黄金法则； “当你在公共分支时，永远不要变基？”因此可能会导致每个 rebase 的人都在进行日常功能分支 rebase 的问题？

如果没有这个，我一辈子都无法弄清楚如何通过两个分支上的修补程序来强制执行线性历史记录。谁能指出我方法的错误？

【问题讨论】：

您可以选择不可能 A（易于阅读的缠结分支）或不可能 B（基本上不是线性的事物的解开线性历史）。 TANSTAAFL

听起来你正在使用 Git Flow 或类似的东西，但如果是这样，这句话不应该是真的，“导致提交多次出现在历史记录中”。仅当您没有将修补程序合并回 release（您是否使用发布？）或 develop 足够快以至于其他人将 PR 复制到另一个分支时，才会发生这种情况。

你试过git log --first-parent吗？这将向您展示如果您使用 squash 合并会得到什么，但还有一个额外的优势是仍然保留提交分辨率以供您查看。

【参考方案1】：

您尝试实现的线性历史方法假设您正在使用基于主干的开发https://trunkbaseddevelopment.com

只要你有两个主要分支，你就会一直为此苦苦挣扎。

解决方案是移至单个主分支，并功能标记您正在进行的工作。这实际上开辟了新的可能性，例如生产中的测试（非常有价值）、按需/持续部署等。