多次从Master合并后发生冲突

Question

我是 Git 和 GitHub 的新手，并试图为一个项目做出贡献，所以我做了一个 fork。该项目包含大量包含文件的文件夹，而我唯一做的就是添加两个文件夹，其中包含一些文件并修改一个文件。过了一会儿，我想跟上原来的主人，并按照https://help.github.com/articles/syncing-a-fork/ 中的建议从上游合并 - 所以我做了一个git merge upstream/master。这为我的 fork 的 master 带来了很多变化。

现在，几个月后我决定再次同步我的 fork 并再次执行 git merge upstream/master。这给我带来了 10 次冲突，这些冲突都在文件中，我自己没有碰过。当然我可以尝试手动合并它们，但我想了解，这是怎么回事，这样我就不会破坏其他人的工作。

问题：

• 为什么这些冲突发生在从上游开始的第二次合并时？

• 我能否以某种方式将我的 fork 的底部更改为最顶部（这就是 rebase 的作用吗？）

• 如何找出两个冲突版本的“更改路径”（它们来自哪里？）

如果有帮助，下面是我所说的分叉：https://github.com/0815fox/DefinitelyTyped

Answer 1

• 很可能原始存储库已重新设置基础，或者您的本地存储库已重新设置基础，您需要执行提取和硬重置以恢复同步。

• 您不太可能在不知不觉中这样做。这通常是不可能的，我能理解的唯一方法是通过重置为第一次提交和反向樱桃选择一次提交一个来创建一个裸分支。这不是 rebase 所做的。 Rebase 可用于将提交压缩在一起，并将新提交移到上游分支上的祖先提交之后，以实现快速向前合并。

您可以使用 git log 检查所有分支的合并路径。

git log --oneline --graph --decorate --all

如果您对文件中特定行的生成时间感兴趣，例如在调查冲突时，请使用 git blame。

git blame -- filename

我的建议是，在您完成调查后，使用您所做的更改创建一个新分支，重置您的上游分支，然后选择您的提交范围。

git checkout -b mybranch
git checkout master
git reset --hard origin/master
git cherry-pick ^your1stSHA..yourLastSHA