尽管我们尽了最大的努力，我们还是在Git存储库中的一个特性分支中陷入了相当棘手的困境。最终的结果是，git diff develop..feature-branch显示了一个完全意想不到的差异。
例如，在develop中添加的一个文件在diff中显示为删除。许多其他文件显示类似的问题，一些丢失，一些添加，许多许多意想不到的更改。一些应该在develop中的文件甚至没有出现在diff中。我们第一次注意到Atlassian Stash中的问题是在我们通过Pull Request检查代码时。挂起的合并是完全不正确的，不能通过合并期间的标准冲突解决来解决。
我们试图解释导致这个问题的原因，我们认为这个问题是由于开发人员在已经推送到原点的特性分支中执行了多次重置。这是为了"还原"在拉取请求代码审查期间建议的一些更改。具体来说，我们认为这是事件的时间轴。
- 从develop 创建的功能分支
- 在特性分支上执行的工作
- 在Atlassian Stash中生成的拉请求(PR看起来不错，但建议进行一些小编辑)
- 开发人员使用重置来恢复一些更改并将这些更改推送到原点
- 同时注意到开发分支和功能分支之间的小冲突
- 开发人员从开发中更新功能分支以调和冲突并推送到原点
- Pull request (diff)显示意想不到的diff，与之前的大不相同。期望提交的文件丢失，反之亦然
- 我尝试撤销(恢复而不是重置)"坏"合并并再次尝试。然而PR/diff显示了对于挂起的合并 的相同的错误更改。
- 然后我了解到开发人员在第一次从开发中合并之前使用了reset。
那么，我有三个问题。
-
我们需要如何"恢复"一个正确的功能分支，以便我们可以将我们的更改合并到正确的开发中?我的想法是在我们的特性分支中创建一个新的"好的"特性分支，这是在重置之前已知的。然后，我可以从"坏"的特性分支中挑选出我们想要的提交到"好"的分支中来重新创建它。最后，我可以将"好的"功能分支合并到开发中，并删除"坏的"功能分支。
-
如果我将"坏的"特性分支合并到开发中，除了文件的不正确状态外，是否会有其他"损坏"泄漏到开发分支中。也就是说，被污染的"坏"特征分支是否会进一步污染发展分支及其下游的任何东西?我当然不打算这么做，但我确实想了解后果。
-
我所描述的重置是否会导致我所看到的问题，或者这可能与其他东西有关?
开发者的"reset"可能不会影响origin，除非他/她对origin进行了"force push"。根据我的经验，当这种事情发生时，它是由于一个糟糕的合并或冲突解决过程(例如，我怀疑上面第6步中的某些东西是罪魁祸首)。直觉是正确的;最好的办法是在合并之前创建一个新的分支。"feature-branch2")，并放弃原来的分支(因为很难撤销合并或任何其他已经被推到原点的更改)，并重试失败的合并。
我不确定"revert"是否真的是你想要做的来撤销错误的合并。我的理解是，"恢复"反向应用单个提交的补丁，并试图反向应用合并听起来很粘，因为合并在一次提交中是2个不同的(我没有大量的"恢复"经验，所以也许可以做到，我不确定)。解决这个问题最安全，最可靠的方法是创建一个新的分支，并停止使用有错误合并的分支。