git“重新定金的黄金法则”是如此重要吗？

最近，我与绝对反对在GIT上对功能分支的重新定位策略的人们进行了讨论。这似乎是一种公认​​的模式，仅对本地私有分支使用rebase，但是当有多个人在同一个功能和分支上工作时，从不使用它，这就是所谓的“重新分配的黄金法则”（如此处所述：https ：//www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview）

我只是对此感到惊讶。我花了3年的时间制定了完整的重新调整策略，大约有20位开发人员共同努力，并猜出了什么有效。

该过程基本上是：

• 创建功能分支，我们将其称为“ myfeature”，并将其推送到origin / myfeature
• 其他人可能会检查出来并进行处理
• 您有时可能会从master重新设置它的基准：从“ myfeature”，git rebase origin / master ; 然后，是的，您必须强制使用它。
• 当其他人想要推送他们的提交时会发生什么？他们只是重新设置它的基础：git rebase origin / myfeature。因此，他们现在处在快速前进的过程中，无需强求就可以推动它。

要遵守的唯一原则是要素分支由某人拥有。所有者是唯一可以推动力量的人。

因此，我承认：只要有推动力，就有犯错误的风险。确实如此。但是也有很多方法可以从错误中恢复，实际上，在3年的开发中，我没有看到很多强制错误，而且当它发生时，我们总能找到一种正确恢复的方法。

那么，为什么这种“黄金基础规则”被如此广泛地接受呢？我还有其他想念的吗？我了解这需要最少的组织（每个策略都需要某些组织），但是它可以工作。

强制推送的问题与您的功能分支和母版无关，而与将母版推到其他人的母版有关–同步将通过您的更改覆盖其母版，而忽略了他们的建议。

考虑到这种危险，有一个原因，就是除非事情搞砸了，否则您根本不应该使用它，而您绝对需要使用它来进行维修。如果SCM系统这样做是因为出了点太严重的错误（在这种情况下，我的第一个方法将是还原备份并重复操作以保持历史记录完整），那么它就永远不必这样强迫。

因此，也许的问题是，为什么您要全部撤离？将功能重新掌握时的“干净”历史记录？如果是这样，那么纯粹出于样式原因，您会丢掉所有有关分支的良好历史记录。恕我直言，快速合并也不是最佳实践，您应该保留所有历史记录，以便可以看到自己的实际操作，而不是之后的版本。

变基并不是必不可少的，因为您说的主要是修饰。有时，合并要简单得多。因此它可以具有一些“实际”价值，但只有“有时”

错误使用rebase可能会造成高昂的成本。如果您不了解紧急情况并查找恢复过程，就不太可能丢失数据，但是“嘿，没人要我修复一段时间……”并不是很好。也没有人花时间在研究恢复和测试上，因为他们本来可以添加功能或压缩错误（或带家人回家）。

有了这种权衡，“很少有人进行改组和强行推动”的结果就不足为奇了。

某些工作流程可以降低风险，例如将其降低为“零，只要您记住允许强制执行的分支和不能强制执行的分支”即可。实际上，它们可能足够安全以证明风险，但人们经常根据更大的民俗来做出选择。那么实际上收益又是很小的，那么风险真正需要多少呢？

要添加其他声音：

是的，如果按照您的描述进行工作，则使用rebase和强制推动没有问题。关键点是：您的团队已达成协议。

关于rebase和的警告是针对没有特殊协议的情况。通常，git会自动保护您，例如，不允许非快进推送。使用rebase和强行推压会超过此安全性。如果您还有其他地方，那没关系。

在我的团队中，如果历史变得混乱，有时我们还会为要素分支重新设置基础。我们要么删除旧的分支，然后使用新名称创建一个新分支，要么我们只是非正式地进行协调（这是可能的，因为我们是一个很小的团队，在存储库中没有其他人工作）。

请注意，git项目本身也具有类似的功能：它们具有一个定期重新创建的集成分支，称为“ pu”（“建议的更新”）。据记录，该分支会定期重新创建，并且您不应该在此基础上进行新工作。

因此，我承认：只要有推动力，就有犯错误的风险。确实如此。但是也有很多方法可以从错误中恢复，实际上，在3年的开发中，我没有看到很多强制错误，而且当它发生时，我们总能找到一种正确恢复的方法。

Git用户倾向于避免共享的可变历史记录的原因是因为没有自动避免或修复这些问题。您必须知道自己在做什么，如果您搞砸了，就必须手动修复所有问题。完全允许一个人进行推力是不直观的，并且与Git的分布式设计相反。如果那个人去度假怎么办？别人是否暂时拥有分支机构？您怎么知道他们不会走遍原始所有者的所有工作？在开源世界中，如果分支机构的所有者在没有正式离开的情况下逐渐远离社区，该怎么办？您可能会浪费大量时间等待将分支机构所有权移交给其他人。

但是真正的问题是：如果您搞砸了并且没有立即意识到这一点，那么经过足够的时间之后，旧的提交最终将消失。到那时，问题可能无法恢复（或者至少可能很难恢复，具体取决于您的备份故事-您是否备份Git存储库的旧副本，即不只是克隆副本？）。

将此与Mercurial的Changeset演化工作（我应该指出，尚未完成或稳定）进行对比。只要更改集未标记为公开，每个人都可以对自己喜欢的历史进行任何更改。这些修改和变基可以完全不受惩罚地推入和拉出，不需要分支机构所有者。永远不会删除任何数据；整个本地存储库只能追加。不再需要的变更集已标记为过时，但可以无限期地保留。最后，当您弄乱历史记录（这被视为日常工作流程的正常部分）时，有一个漂亮的命令可以自动为您清理历史记录。 这是那种UX他们四处修改共同的历史之前，人们期待。