idea解决代码冲突-git分布式合并分支-加git回滚操作

---

前言

第一次接触项目发版的工作，记录一下解决版本冲突合并问题的心得。
适用场景：分布式项目，多人使用自己分支开发，最后合并自己的代码分支给主分支。
话不多说，直接看图

---

一、分支如何合并？

1.全部拉下来（这个拉取是全部拉取，既保证自己的分支最新，同时也把远端的分支都拉到最新），如果没有图一的拉取图标，这是因为自己没设置显示，可以参考图二的拉取方法。

图一
图二

2.注意自己是不是dev分支（也就是自己项目的主分支，别的分支要合到的分支），如果不是需要切换为dev分支
（右下角有图标，可以看此时属于哪个分支，下图为切换分支方法英文界面的名字应该是checkout）

3.合并冲突（某个模块开发完，该模块的开发者将自己的开发分支推送给主分支，此时合并时需要注意代码冲突）

之后界面会显示冲突文件，可以点开看哪里冲突，解决冲突第一步，点击左上角的All，合并没有冲突的地方，之后开代码确定dev分支和新提交的谁的代码对（一般都是新提交的对，不过有时候拿不准可以问提交代码的人），解决完冲突后记得推送，推送给dev就可以了

二、为什么出现冲突？

一般来说，每个开发者推送代码前都必须拉取最新的代码，自己在本地解决冲突后再进行推送（注：拉取前必须先提交，也就是commit，不然可能造成自己的代码被别人的代码冲掉），相当于大家在一个分支开发，按照这个流程不会出现什么冲突。
但是分布式开发并且项目已经上生产时将改变此流程，每个开发者从生产环境master拉取创建一个最新代码分支例如master_zhangsan_2021_11_01分支，之后在这个分支上进行开发，当开发完后需要将其合并到sit测试环境，此时相当于master_zhangsan_2021_11_01分支的拉取是基于master分支上的，而合并操作则是在sit分支，而sit测试分支必定比master分支的代码内容多（只有版本迭代，也就是把sit分支合并到master时，二者才会相同），这就导致代码可能会有冲突，因为自己写的地方，别人也可能在别人自己的分支的这个位置写代码了，这将出现冲突问题，尤其是复用高多人开发多的模块。

---

三、如何避免？

1.项目管理者让单人负责单模块，尽量不要让多人同时间段对一个模块一个页面操作。
2.如果要开发的内容很多时间很紧，尽量让生产发版频繁一些，让测试分支与生产分支的代码不要差太多，避免解决冲突。
3.如果自己的项目并不是在生产环境下开发新功能和修改bug，推荐使用开发分支dev作为拉取和推送（而不是从master拉取，合并到sit），最后再把dev分支整体合并到sit测试环境。

四、为什么要从生产环境master拉取创建一个最新代码分支，当开发完后再将其合并到sit测试环境？

开发者从项目从生产环境master分支拉取开发，可以保证开发者的代码上生产环境后必定生效，毕竟就是在生产环境的代码下开发的。这种流程场景一般是项目开发完一部分，这部分已经上生产了，接下来开发其他部分要上生产，或者修改生产上的问题。该方法弊端是，从生产上拉取的分支但是不能直接上生产，需要先推送到测试环境的分支，测试通过后再合并到生产。测试环境又与生产环境不同，这就导致测试环境代码冲突毕竟严重。
如果项目不是上述流程场景，而是多人共同开发dev分支，最后整体上测试环境，最后上生产环境，则冲突会小很多。

五、回滚操作

1.提交到本地后，还没有push到远端时的回滚操作,可以点击查看历史，点击undo Commit 这种方式最推荐，不会影响别人代码与自己代码。
2.如果是以前的提交有问题，那么可以选择使用revert commit和revert current Branch here(慎用，会丢失提交记录)。
注意：回滚操作要小心使用，不然会造成丢失他人与自己代码问题。

总结

以上就是今天要讲的内容，本文仅仅简单介绍了代码冲突原因、解决方法。不同项目代码合并流程不同，只能作为参考，另外作为一名开发人员，必须适当了解一定的git合并分支，撤回提交，回退版本等操作，避免出现自己代码丢失或者导致他人代码丢失的现象出现。

最后：注意休息，保护好身体；不要忘了学习，可以少学，不要停止 人生如逆水行舟不进则退