我是Git的新手，在误解了帮助文章后犯了一个（愚蠢的）错误，我不确定如何使用Git来完全解决问题，而不是手动将更改重新引入目标分支。
S---sc1---sc2---sc3-----sc4----M4---R1---M5---sc5
\ \ / /
T1-------------------M2---M3--------R2
\ \ /
F---fc1---fc2---M1
一些注意事项：在这种情况下，S是主要分支，T1是从S拉出的团队分支，而F是我从{{ 1}}。
我已经设置了自动合并，因此当对T1分支进行提交时，它们将通过连续集成运行，然后自动合并到T1。 S分支中有一个文件与另一个团队成员的提交与T1有合并冲突，因此，我决定在完成S上的工作后再进行修复。 / p>
我将F合并到T1（F）中，然后将M1合并到F（T1）中。鉴于我过去与合并冲突解决方案所遇到的问题均不符合我的期望，我想我应该尝试一些新的方法：将冲突文件从M2合并到S，解决合并发生冲突，从合并中删除所有其他文件，然后允许进行持续集成以合并所有T1
我没有提交就从S到S（T1）进行了合并，解决了冲突，从合并中删除了其他（〜200）个文件，然后提交了。这会自动合并到M3（S）。
我立即注意到，不包括这200个文件，似乎完全消除了更改，这相当于在两个团队中进行了大约一个月的工作。我（错误地）认为最好的措施是迅速采取行动，并在我的错误进入任何人的本地存储库之前还原合并提交M4和M4。我首先还原了M3（M4），一旦提交，我还原了R1（M3）。我认为这是正确的顺序，因为我不确定启动自动合并时是否会出现其他问题。最终R2已提交并自动合并到R2（{ {1}}。
这解决了擦除其他所有人的更改的问题，但是我在S中的所有更改以及最初存在合并冲突的文件都从M5中消失了。我能够将单个文件的更改直接提交到F（S），但是S中的更改要复杂得多。它们仍然生活在sc5中，但是由于它们是F的一部分从T1还原的，所以我不能仅仅将它们提交回来。
我一天中的大部分时间都在尝试找出如何最好地将这些更改提高到S，但是R1和S似乎并不会尽管我很清楚自己在这方面可能是错的，但是可以做我所需要的。如果有人在Git方面做得比我好得多，那么至少可以提出一个起点，那就太了不起了。谢谢！
编辑：从图表中删除了无用/令人困惑的点。由于我尝试与git rebase解决的合并冲突，git cherry-pick没有自动合并到M2。
编辑2：在阅读了torek的精彩解释之后，我开始尝试重新设置基准。我忘记了在整个S的历史中，我多次将M3分支合并到T1分支中，因为此功能分支跨越了多少时间。这意味着要解决许多合并冲突。
在torek对此做出回应时，我尝试了合并壁球。我最初的想法是我需要将新的分支从合并壁球合并到F分支，然后再将F分支合并到T1，但是我遇到了同样的问题它看不到变化。我认为这是因为T1中已经存在更改，因此基本上只是将相同的，先前还原的更改反馈回S中，而不希望它们。
编辑3：感谢torek的解释非常详尽的答案（非常感谢！），我将介绍合并壁球，然后将其结果合并到解决冲突后，T1分支。