git - 浅叙冲突的产生

git每个提交记录存在唯一一个顺序的加签串节点标识，
如果两个节点发生争抢这个唯一的提交顺序节点即会发生冲突让你解决：

案例：

a, b两个用户，以及改同一个test.js文件，test.js文件内容初始：console.log(99);

commit log 节点

1.  console.log(99);        1a9123ed      // a, b原始同一份
2.  console.log(88);        de13b5a7      // a顺序提交，为1节点的下一个节点
2.  console.log(77);        ab21823e      // b强制覆盖提交，为1节点的下一个节点

操作步骤

a, b同为这一份代码，

a. 修改内容提交为console.log(88); // de13b5a7

b. 未更新a刚提交的节点，b本地节点串是1a9123ed，
b打算修改内容，console.log(77); git commit 和git push发生报错需要先更新再提交，但仍使用git push -f，强制覆盖提交。 // ab21823e

a. 本地是之前顺序提交的2节点，进行git pull，发生出现冲突了

原来如此，提交日志存在了2个日志节点这是不允许的啊，所以需要fix解决冲突重新提交。

冲突发生：
1、他人冲突，强制git push -f 提交冲突在其他人，
2、本地冲突，如果本地git commit 和git push后再git pull, 冲突先在本地，
3、分支冲突，当然，代码分支合并冲突也是同理可以解释，2个合并分支的提交节点串，
如果2个分支都从原始主分支拉取的某个节点做了修改，当合并的时候即会存在以上同理冲突问题。

当然，

如果项目目录分工明确, 一个目录下文件是一个开发负责的，则fix分支发布后及时合并到未发布的dev分支即可，节点都是顺序的不会出现冲突。

如果存在多人开发，即fix分支发布期间的提交节点和dev分支提交节点，可能存在并行的关系，则即使是发布后及时将fix同步到dev，还是会存在冲突问题，这时候就需要找到拉上负责的相关开发碰面，一段段解决哪段代码是最终需要的。

（冲突比对产生一定是进行了git commit和git push后产生了唯一节点加签串，然后git pull后2个节点争抢而发生的冲突。）