从git分支恢复，其中多个重置'；完成并推送到原点（即，大西洋储藏室）

尽管尽了最大的努力，我们还是在Git存储库中使用了一个特性分支，使自己陷入了困境。最终结果是，

gitdiff develope..feature分支

显示了一个完全出乎意料的差异

例如，在develope中添加的一个文件在diff中显示为delete。许多其他文件显示类似的问题，一些丢失，一些添加，许多意外更改。一些应该在

develope

中的文件甚至没有出现在diff中。当我们通过Pull请求查看代码时，我们首先在Atlassian Stash中注意到了这个问题。挂起的合并完全不正确，无法通过合并期间的标准冲突解决方案解决

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

从“开发”创建的要素分支

在功能分支上执行的工作

在Atlassian Stash中生成的拉取请求（PR看起来不错，但建议进行一些小的编辑）

开发人员使用重置来恢复一些更改，并将这些更改推送到源

同时，开发部门和特色部门之间也注意到了一些小冲突

开发人员从“开发”更新功能分支以协调冲突并推送到源

拉请求（diff）显示意外的差异，与之前的差异大为不同。预期提交的文件丢失，反之亦然

我尝试撤消（还原而不是重置）“错误”合并并重试。但是，PR/diff为挂起的合并显示相同的错误更改

然后我了解到，开发人员在第一次合并develope之前的某个地方使用了reset

所以，我有三个问题

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

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

我所描述的重置是否会导致我所看到的问题，或者这可能与其他问题有关

开发人员的“重置”可能不会影响origin，除非他/她对origin进行了“强制推送”。根据我的经验，当出现这种情况时，是由于错误的合并或冲突解决过程（即，我怀疑上面第6步中的某些东西是罪魁祸首）。直觉是正确的；最好的办法是在错误合并之前创建一个新分支（例如“feature-branch2”），并放弃原始分支（因为很难撤消已推送到原点的合并或任何其他更改），然后重试出错的合并

---

我不确定“还原”是否真的是要撤消错误合并的操作。我的理解是，“恢复”反向应用来自单个提交的补丁，尝试反向应用合并听起来很棘手，因为合并在一个提交中有两个不同之处（我对“恢复”没有太多经验，所以可能可以完成，我不确定）。解决此问题的最安全、最可靠的方法是创建一个新分支，并停止使用合并错误的分支。

发生此情况的唯一方法是，如果其他开发人员在步骤4中对源站进行“强制推送”（因为如果不是快进合并，推送将被源站拒绝）。你知道情况是否如此吗？Patrick，不知道。虽然开发人员没有对origin进行“强制推送”，但更改是推送的。答案是从上一次已知的良好提交创建一个新分支。我们决定，我们也不需要从最后一个已知的良好提交中挑选任何提交，而只是合并到新分支中而没有问题。