解决git合并的冲突问题_git多人开发合并冲突

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

1.1 实验一

实验目的：

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

实验步骤：

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

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

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

实验结果：

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

实验分析：

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

1.2 实验二

实验目的：

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

实验步骤：

• 工作者一
  1. 给工作者一创建一个文件夹，表示工作者一的工作区
  2. 使用git clone把远程仓库拷贝到工作区
  3. 在工作区对项目中的文件X做出修改
  4. 打开windows的凭据管理器，修改已保存的登录凭据（此处以gitee为例，修改gitee的登录凭据即可），修改为工作者一的用户名和密码
  5. 使用git add .和git commit -m和git push将最新分支提交到远程仓库
• 工作者二
  1. 给工作者二创建一个文件夹，表示工作者二的工作区
  2. 使用git clone把远程仓库拷贝到工作区
  3. 在工作区对项目中的文件X做出修改
  4. 打开windows的凭据管理器，修改已保存的登录凭据，修改为工作者二的用户名和密码
  5. 使用git pull拉下最新分支，观察结果
  6. 使用git add .和git commit -m和git push将本地分支提交到远程仓库，观察结果
  7. 使用git pull来下最新分支，观察结果
  8. 使用git reset --merge撤销git pull导致的合并
  9. 修改冲突位置的代码，可以选择在文件中手动修改：同时保留远程仓库和本地仓库的代码。可以选择IDE修改：可以选择留下任何内容（推荐使用专业IDE例如VSCODE，会有merge editor，可以直接指定merge合并结果。否则需要手动输入其它git 指令来合并）
  10. 使用git add .和git commit -m和git push将本地分支提交到远程仓库，观察结果

实验结果：

1. 显示git pull失败，提示需要git stash或git commit
2. 显示git push失败，提示当前仓库版本低于远程仓库版本并有分叉
3. 显示文件X处产生git merge冲突
4. 显示上传远程仓库成功

实验分析：

1. git merge时如果工作区有修改，那么不会进行
2. git push失败是因为明本地仓库版本落后于远程仓库，并且出现了分叉，这样才会被拒绝
3. git merge失败是因为两个人都对X文件修改，不清楚保留哪一个修改
4. 当前仓库分支合并后版本高于远程仓库版本，上传成功

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合并。

• 项目开发时的规范：

  • 不要fork或clone多份远程仓库到本地，保证本地仓库只有一个。当切换分支时，先处理当前修改的提交。
  • 每次开发时应先检查当前分支版本。每次提交时应先检查分支版本。避免把代码提交到错误分支。