在 repo post-rebase 上拉取提交

Question

我正在寻找一种简单的方法来在变基后引入额外的提交或一个很好的理由告诉某人不要变基。

基本上我们有一个项目，crons。我经常对此进行更改，并且项目的维护者会在我提出请求时拉入更改并每次重新设置基准。

这通常没问题，但在两种情况下可能会导致问题：

• 同时从两个分支释放
• 之后必须发布额外的提交。

例如，我提交修订版1000。维护者拉动和变基以创建修订版1000'，但同时我意识到一个可怕的错误并创建修订版1001（1000 的子级）。由于目标分支中不存在1000，这会创建一个不可用的合并，维护者通常会嘲笑我并告诉我再试一次（这需要我在1000' 重新检查主分支并创建并从另一个结帐手动导入补丁）。我相信您会看到我尝试同时从两个单独的分支释放时会发生同样的问题。

无论如何，一旦主分支有了1000'，有什么办法可以拉入1001，而不必再次合并相同的更改？或者变基会破坏这个？不管我能说什么让维护者停止变基？他是不是用错了？

Answer 1

告诉你的维护者不要再做傻瓜**。

变基只应由您完成，即创建您想要变基的变更集的人，并且不对以下变更集执行：

• 已与其他人共享
• 从别人那里得到的

您的维护者可能想要一个非分布式版本控制系统，例如 Subversion，其中变更集遵循一条直线，而不是 DVCS 的分支性质。在这方面，Mercurial 的选择是错误的，或者 Mercurial 的使用是错误的。

还请注意，变基是更改历史记录的一种方式，并且由于 Mercurial 不鼓励这样做（更改历史记录），因此变基仅作为扩展提供，而不是“开箱即用”的香草Mercurial 配置。

所以回答你的问题：不，因为你的维护者坚持打破 DVCS 的本质，这些工具会与你（和他）对抗，你将很难获得与之合作的工具你。

告诉您的维护人员接受 DVCS 的真正工作原理。现在，他可能仍然坚持不接受 他的 存储库中的新分支或头，并坚持在将单个头推回他的存储库之前拉取和合并，但这没关系。

但是，重新设置共享变更集不是。

如果你真的想使用rebase，正确的做法是这样的：

1. 您从某个源存储库中提取最新更改
2. 您在本地提交了大量变更集、修复错误、添加新功能等等
3. 然后您尝试推送，被告知这将在目标存储库中创建新的头。这告诉您，目标存储库中有新的变更集，您上次拉取时没有得到，因为它们是在那之后添加的
4. 相反，您拉动，这将在您的本地存储库中添加一个新头。现在，您有了从新变更集中创建的 head，以及从其他人创建的源存储库中检索到的 head。
5. 然后，您在从源存储库获得的变更集之上重新设置变更集，实质上是移动历史记录中的变更集，以显示您从当前源中的最新变更集开始工作存储库
6. 然后您尝试新的推送，成功

最终结果是目标存储库和您自己的存储库将有一个更多线性变更集历史记录，而不是一个分支然后一个合并。

但是，由于 DVCS 中有多个分支非常好，您不必经历所有这些。您可以合并，然后继续工作。这就是 DVCS 应该如何工作的。变基只是一个额外的工具，如果你真的想要，你可以使用。