在回购后重基上的拉提交
我正在寻找一种简单的方法，以便在重基后引入额外的提交，或者有一个很好的理由告诉别人不要重新定位。
本质上，我们有一个项目，crons。我经常对此进行更改，项目的维护人员每次请求并重新定位时都会进行更改。
这通常是可以的，但在两种情况下都可能导致问题：
- 双枝同时释放
- 之后必须释放额外的提交。
例如，我提交了修订版1000。维护人员提取并重新创建修订1000'，但几乎同时我意识到了一个可怕的错误，并创建了修订版1001 (子1000)。由于目标分支中不存在1000，这会创建一个不可用的合并，维护人员通常会嘲笑我并告诉我再试一次(这要求我在1000'获得主分支的新签出并从其他签出处手动创建和导入修补程序)。我相信，当我试图同时从两个独立的分支中释放时，您可以看到同样的问题是如何发生的。
不管怎么说，一旦主分支拥有了1000'，是否有什么可以在无需再次合并相同更改的情况下引入1001呢？还是重新定位会毁了这一切？不管怎么说，我能说些什么让保持人停止重新定位吗？他是不是用错了？
回答 1
Stack Overflow用户
发布于 2013-01-26 20:59:58
告诉你的维护者不要再做杰克**。
重基是只应该由您完成的事情，它创建了您想要重基的变更集，而而不是则创建了以下变更集：
- 已经和别人分享了
- 从别人那里得到的
您的维护者可能需要一个非分布式版本控制系统，比如Subversion，其中变更集遵循直线，而不是DVCS的分支性质。在这方面，选择汞是错误的，或使用汞是错误的。
还要注意的是，重基是改变历史的一种方式，而且由于Mercurial不鼓励(更改历史)，因此重基只能作为扩展，而不是“开箱即用”的香草汞配置。
所以，要回答你的问题:不，因为你的维护者坚持打破DVCS的本质，这些工具会与你(和他)对抗，你将很难找到工具与你合作。
告诉你的维护者接受DVCS是如何真正工作的。现在，他可能仍然坚持在他的存储库中不接受新的分支或头，并且坚持在将一个头推回他的存储库之前，您要拉和合并，但这没关系。
然而，重新设置共享变更集的基础并不是这样。
如果您真的想使用重基，正确的方法是这样做：
- 从某个源存储库中提取最新的更改。
- 您在本地提交了许多更改集，修复了bug，添加了新特性，诸如此类。
- 然后尝试推送，被告知这将在目标存储库中创建新的头。这将告诉您，在目标存储库中有一些新的更改集是您上次提取时没有得到的，因为它们是在之后添加的。
- 相反，您可以拉，这将在您的本地存储库中添加一个新的头。现在，您有了从您的新变更集中创建的头部，以及从其他人创建的源存储库中检索到的头部。
- 然后，将您的变更集重新建立在从源储存库中得到的变更集之上，实质上是将您的变更集在历史记录中移动，以显示您从当前源储存库中的最新变更集开始您的工作。
- 然后你尝试一个新的推动，成功。
最终的结果是目标存储库和您自己的存储库将有一个更线性的变更集历史记录，而不是一个分支，然后是一个合并。
但是，由于多个分支在DVCS中是非常好的，所以您不必经历所有这些。你可以直接合并，然后继续工作。这就是DVCS的工作原理。重基只是一个额外的工具，如果你真的想用的话。
https://stackoverflow.com/questions/14541155
复制相似问题
腾讯云开发者
