所以这个场景是很基本的：我在分支X上 checkout 了一个git repo。做了一些修改，执行了一次提交并推送了它们，到目前为止一切都很好。2-3天内没有其他变化。之后我回来，运行了一个git status以确保我没有更改，做了一个git pull origin X，我在几个文件上遇到了冲突。这怎么可能？老实说，我不知道其他同事在这2-3天里在那个分支上做了什么（也许是一些变基，强制推送等），但是，只要我的本地克隆没有变化，拉怎么会导致冲突呢？谁能解释一下，举个例子？
mrzz3bfm1#
git pull是两个命令的组合：git fetch，然后是git merge或git rebase（第二个命令取决于您的配置以及传递给git pull的选项）。“冲突”只能发生在第二步。如果你不知道冲突来自哪里，你可以通过简单地取消合并或变基来将本地分支返回到合并前的状态：
git pull
git fetch
git merge
git rebase
# run: git merge --abort # or: git rebase --abort # if in doubt, run one then the other
一旦你中止了合并或变基，你就恢复了本地分支，并且仍然有git fetch的结果：* 远程分支 * 已更新。检查您在本地克隆中看到的历史记录：
git log --oneline --graph mybranch origin/mybranch # or: # - @ is a shortcut for 'HEAD' or 'the current commit' # - @{u} is a shortcut for 'HEAD@{upstream}' or 'the upstream branch of my active branch' git log --oneline --graph @ @{u}
gitk
gitg
git-extensions
git-kraken
你应该有机会看到什么改变了。一旦你对发生的事情有了更好的理解，你就可以跑了
git merge origin/mybranch git merge @{u} # or git rebase origin/mybranch git rebase @{u}
重新应用与git pull的第二步完全相同的操作，或者在合并或重新定基之前先在分支上做一些更改（删除一个提交，cherry-pick另一个提交...）。如果你想避免“为什么我会有我没有意识到的冲突？””的情况下，停止使用git pull，使用git fetch，然后使用git merge或git rebase。这使您有机会在处理它们之前检查您收到的更改。
1条答案
按热度按时间mrzz3bfm1#
git pull是两个命令的组合：git fetch，然后是git merge或git rebase（第二个命令取决于您的配置以及传递给git pull的选项）。“冲突”只能发生在第二步。如果你不知道冲突来自哪里，你可以通过简单地取消合并或变基来将本地分支返回到合并前的状态：
一旦你中止了合并或变基，你就恢复了本地分支，并且仍然有
git fetch的结果：* 远程分支 * 已更新。检查您在本地克隆中看到的历史记录：
gitk、gitg、git-extensions、git-kraken、IDE集成查看器...），查看当前分支及其远程分支的组合历史记录你应该有机会看到什么改变了。
一旦你对发生的事情有了更好的理解，你就可以跑了
重新应用与
git pull的第二步完全相同的操作，或者在合并或重新定基之前先在分支上做一些更改（删除一个提交，cherry-pick另一个提交...）。如果你想避免“为什么我会有我没有意识到的冲突？””的情况下，停止使用
git pull，使用git fetch，然后使用git merge或git rebase。这使您有机会在处理它们之前检查您收到的更改。