2

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

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

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

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

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

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

4

1 回答 1

4

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

变基只能由您完成，即创建您要变基的变更集的人，而不是对以下变更集执行的操作：

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

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

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

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

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

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

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

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

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

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

于 2013-01-26T20:59:58.127 回答