解决git合并的冲突问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了解决git合并的冲突问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1.实验问题：多人协作下的合并冲突问题

1.1 实验一

实验目的：

模拟某些情况下使用git pull下拉远程仓库代码时覆盖了自己已有代码

实验步骤：

使用git clone拷贝远程仓库到本地

使用git reset --hard把本地仓库工作区，版本库都回退到很久之前的版本

使用git pull下拉远程仓库最新分支，观察本地仓库代码变化

实验结果：

本地仓库的所有代码都被完全替代成远程仓库的最新版本

实验分析：

在git pull拉下之后远程仓库分支之后，对应了之前总结的git merge的fast forward模式，因为本地仓库分支和远程仓库分支不分叉，因此进行了fast forward模式合并

1.2 实验二

实验目的：

模拟某些情况下，多人共同开发相同文件，在git pull时发生的冲突

实验步骤：

工作者一

给工作者一创建一个文件夹，表示工作者一的工作区

使用git clone把远程仓库拷贝到工作区

在工作区对项目中的文件X做出修改

打开windows的凭据管理器，修改已保存的登录凭据（此处以gitee为例，修改gitee的登录凭据即可），修改为工作者一的用户名和密码

使用git add .和git commit -m和git push将最新分支提交到远程仓库

工作者二

给工作者二创建一个文件夹，表示工作者二的工作区

使用git clone把远程仓库拷贝到工作区

在工作区对项目中的文件X做出修改

打开windows的凭据管理器，修改已保存的登录凭据，修改为工作者二的用户名和密码

使用git pull拉下最新分支，观察结果

使用git add .和git commit -m和git push将本地分支提交到远程仓库，观察结果

使用git pull来下最新分支，观察结果

使用git reset --merge撤销git pull导致的合并

修改冲突位置的代码，可以选择在文件中手动修改：同时保留远程仓库和本地仓库的代码。可以选择IDE修改：可以选择留下任何内容（推荐使用专业IDE例如VSCODE，会有merge editor，可以直接指定merge合并结果。否则需要手动输入其它git 指令来合并）

使用git add .和git commit -m和git push将本地分支提交到远程仓库，观察结果

实验结果：

显示git pull失败，提示需要git stash或git commit

显示git push失败，提示当前仓库版本低于远程仓库版本并有分叉

显示文件X处产生git merge冲突

显示上传远程仓库成功

实验分析：

git merge时如果工作区有修改，那么不会进行

git push失败是因为明本地仓库版本落后于远程仓库，并且出现了分叉，这样才会被拒绝

git merge失败是因为两个人都对X文件修改，不清楚保留哪一个修改

当前仓库分支合并后版本高于远程仓库版本，上传成功

2.实战问题：单人导致的合并冲突问题

2.1 同一分支下单人导致的合并冲突问题

引入：提升切换分支的速度

正在最新的还没有上线的分支修改文件，但是老的已经上线的分支上出现了错误，需要切换分支修改。而当前分支修改的文件很多，功能没有开发完全，因此有很多eslint问题导致不能直接提交并发送到远程仓库。

老的解决方案：

想要快速切换分支，不想一个个把功能没开发完导致的eslint警告给修改掉。就从远程仓库clone了多份一样的仓库到本地。然后修改时不切换分支，直接在另一个clone的项目文件上修改。

产生的问题：

这通常来讲没有问题。因为修改的老分支上的老代码一般当前版本不再修改，一般不会有冲突。但是有时候可能在clone的项目1上修改了当前分支的文件并提交，过了一段时间忘记了自己在clone的哪个分支上提交文件了，你可能打开了clone的项目2。这时你必须git pull拉取最新代码，但实际上可能会忘记这个操作。原因是文件都是由自己修改，当前本地仓库版本一定大于等于远程仓库，不需要git pull。但是clone多份项目下来，会有本地仓库版本小于等于远程仓库的情况，这需要我们关注更多的版本细节。因此这种解决方案不是一种好主意。

2.2 不同分支下单人导致的合并冲突问题

引入：修改已上线分支的问题

在最新未上线的分支（例如7.1.50）中进行开发时，上一个版本的老分支（例如7.1.40）出现的问题需要修改。此时需要切换分支修改。但是有时候改完之后，忘记切回最新分支了，然后继续在老分支上开发最新的功能并提交，当你发现时你的同事已经进行了若干次提交，如果你进行回滚，就会丢失同事的修改。此时选择继续在最新分支上进行开发。当老版本分支进入稳定版本后，会把老版本分支和当前分支进行合并。此时就会出现问题，同一份文件都是自己修改，但是无法直接合并，因为将分支的提交记录看作树，那么你自己修改的文件在7.1.40和7.1.50中不存在祖先孩子关系，无法直接合并，这样就造成了冲突。

解决方案：

很简单，直接选择合并的内容即可

3.总结

解决冲突的最好方案是：

git pull之后手动修改：
- 只保留远程仓库的代码，剪切你的修改，等到合并成功后再对文件进行修改并重新提交
- 同时保留远程仓库的代码和你的代码，合并可以成功
- 使用IDE提供的merge editor，可以选择性保留任意内容
git pull之前修改：
1. 只保证工作区做出了修改，如果提交到了版本库，那么使用git reset撤销提交。
2. 之后使用git stash将工作区修改缓存进栈。
3. 之后git pull下拉代码，直接进行fast forward合并。
4. 再进行git stash pop出栈，自动发生git merge合并，此时你还需要遵循上述方案选择如何merge合并。
项目开发时的规范：文章来源地址https://www.toymoban.com/news/detail-468032.html
- 不要fork或clone多份远程仓库到本地，保证本地仓库只有一个。当切换分支时，先处理当前修改的提交。
- 每次开发时应先检查当前分支版本。每次提交时应先检查分支版本。避免把代码提交到错误分支。