迹忆客 专注技术分享

大多数时候，当我们应用 git push 或 git merge 时，最终会发生一些冲突。在某些情况下，合并冲突的解决方案就像丢弃本地更改或远程或其他分支更改一样简单。

当 Git 无法弄清楚如何合并两个冲突的更改时，它会创建一个冲突请求。冲突请求是一种描述问题的特殊补丁，它包含冲突更改的双方（我们的和他们的）以及合并尝试的结果。

当两个团队成员处理相同的文件并在该文件中发生冲突时，Git 将冲突应用于我们的工作文件。然后我们可以编辑生成的文件，Git 将记录我们的更改。如果确实发生了冲突更改，Git 会将文件标记为处于冲突状态。有几个命令可以解决该特定分支中的冲突。

当两个或更多人在同一个仓库中处理同一个文件时，冲突最常见。但是，当在文件中发现冲突时，Git 会非常聪明和聪明地以非常棒的方式解决冲突。Git 使用冲突标记来显示文件的哪些部分发生冲突。冲突标记是放置在文件冲突部分两侧的小散列。

拉不单独使用。它在从远程服务器获取数据的帮助下使用，然后与本地仓库中的更改应用合并。如果我们愿意，可以执行下面提到的这两个操作。

git fetch
git merge origin/$CURRENT_BRANCH

上面提到的 origin/$CURRENT_BRANCH 的含义如下。

• Git 将应用合并选项并应用来自远程仓库的更改，即 origin。
• 这被添加到 $CURRENT_BRANCH
• 目前在我们本地签出的分支机构中不存在

git pull 不仅是推荐的，它只是运行 git fetch 后跟 git merge。我们将进行 3 次合并，通过这些合并，Git 将执行 3 次 fetch 操作，其中一次 fetch 就是我们所需要的。

git fetch origin   # it will update all our origin/* remote-tracking branches
git checkout new branch        
git merge origin/new branch     
git checkout master
git merge origin/master
git merge -X theirs new branch  
git push origin master   

上面提到的命令将有效地忽略我们要合并的分支上的任何不同更改，并在我们要合并到的分支上开发一个新的提交，所有提交都在该分支上合并。

我们还可以在普通合并中使用 --ours 来合并我们要合并的分支中的所有更改，然后跳过我们要合并到的分支中存在的任何文件，有效地在两者之间进行三向合并分支，然后只使用要合并到的分支中的文件。

我们发现使用 git merge --ours 合并文件然后使用 git rebase -i 手动重新应用我要合并的分支中的更改要容易得多。

上述命令不适用于有冲突的文件，但我们发现以下命令可以解决冲突。

git checkout file_with_conflict
git merge --ours --no-commit file_from_branch_with_conflict
git reset --hard git add file_with_conflict git commit -m