1

尽管尽了最大的努力，我们还是让自己在 Git 存储库中使用了一个功能分支。最终结果是 agit diff develop..feature-branch显示了完全出乎意料的差异。

例如，在开发中添加的一个文件在差异中显示为删除。许多其他文件显示了类似的问题，一些缺失，一些添加，许多意想不到的变化。一些应该存在的文件develop甚至没有出现在差异中。当我们通过 Pull Request 查看代码时，我们首先注意到 Atlassian Stash 中的问题。挂起的合并是完全不正确的，在合并期间无法通过标准冲突解决方案来解决。

我们试图破译造成这种情况的原因，我们认为问题源于开发人员对已推送到源的功能分支中的提交执行了多次重置。这是为了“恢复”在拉取请求代码审查期间建议的一些更改。具体来说，我们认为这是事件的时间表。

  1. 从开发创建的功能分支
  2. 在功能分支上执行的工作
  3. 在 Atlassian Stash 中生成的拉取请求（PR 看起来不错，但建议进行一些小的编辑）
  4. 开发人员使用重置来恢复一些更改并将这些更改推送到原点
  5. 同时注意到开发和功能分支之间的小冲突
  6. 开发人员从开发更新功能分支以协调冲突并推送到原点
  7. 拉取请求 (diff) 显示出意料之外的差异，与之前的差异截然不同。预期提交的文件丢失，反之亦然
  8. 我尝试撤消（还原而不重置）“坏”合并并重试。但是 PR/diff 显示了对于挂起的合并相同的错误更改
  9. 然后我了解到开发人员在第一次从开发中合并之前使用了重置。

所以，我有三个问题。

  1. 我们如何需要“恢复”一个更正的功能分支，以便我们可以正确地将我们的更改合并到开发中？我的想法是从我们的功能分支中的一个提交中创建一个新的“好”功能分支，该分支已知会在重置之前发生。然后我可以从“坏”功能分支中挑选我们想要的提交到“好”分支中重新创建它。最后，我可以将“好”功能分支合并到开发中并删除“坏”功能分支。

  2. 如果我将“坏”功能分支合并到开发中，除了文件的不正确状态之外，还会有任何其他“损坏”泄漏到开发分支中。也就是说，被污染的“坏”功能分支会进一步污染开发分支及其下游的任何东西吗？我当然不打算这样做，但我确实想了解后果。

  3. 我所描述的重置会导致我看到的问题还是这可能与其他问题有关？

4

1 回答 1

1

除非他/她对原点进行了“强制推送”，否则开发人员的“重置”可能不会影响原点。根据我的经验，发生这种情况是由于错误的合并或冲突解决过程造成的（即我怀疑上面第 6 步中的某些事情是罪魁祸首）。本能是正确的；您最好的选择是在错误合并之前创建一个新分支（例如“feature-branch2”）并丢弃原始分支（因为很难撤消合并或已经推送到源的任何其他更改）并重试合并那变坏了。

我不确定“恢复”是否真的是您想要撤消错误合并的操作。我的理解是“还原”反向应用来自单个提交的补丁，并且尝试反向应用合并听起来很粘，因为合并是 1 个提交中的 2 个差异（我没有大量的“还原”经验，所以也许可以做到，我不确定）。解决此问题的最安全、最可靠的方法是创建一个新分支并停止使用合并错误的分支。

于 2014-07-21T13:20:14.337 回答