一般在push的时候是不是都会先pull一下以保证代码最新，但是如果以下场景怎么办：
A：push，但是git提示过期于是进行pull，pull之后发现有冲突，然后merge B：在Amerge的过程向服务器push了。 A：等他merge完，在push的时候服务器又变化了,再pull - merge .....
这样会不会导致A一直没法push？
业精于勤，荒于嬉;行成于思，毁于随。
第一次 merge 时产生的冲突的原因已经在本地解决了， 如果其他人 push 的代码对这部分没有变更的话， 再次 merge 会很顺利的， Git 会自动进行处理，不用过于担心。
如果总是在 merge 的时候产生冲突，那么说明冲突部分的代码极端不稳定， 需要开发人员之间进行沟通，彻底解决，或者采用一些方法绕开。
merge了后就是一个新版本了，push发现其他版本了后，再继续merge一个版本出来。
总有一天可以push上去的。
这个问题应该分两种解决方法： 第一种：应该是只有版本差异过大的时候，才必须先pull + merge才能push。但是你merge之后，版本差异不大的时候，可以push。 第二种：每个人应该保持一个自己的分支。先push到自己的分支上，然后再从服务器端merge到master上。
A和B可以商量好，达成一致，都只rebase不merge。这样历史看起来也比较好看，一根线，不乱。
如果出现这样的问题，那说明A、B之间的代码耦合度太多，需要重新分工
既然冲突了就merge呗，一直merge到他和你没冲突就可以push上去啦
第一次 merge 时产生的冲突的原因已经在本地解决了， 如果其他人 push 的代码对这部分没有变更的话， 再次 merge 会很顺利的， Git 会自动进行处理，不用过于担心。
如果总是在 merge 的时候产生冲突，那么说明冲突部分的代码极端不稳定， 需要开发人员之间进行沟通，彻底解决，或者采用一些方法绕开。
merge了后就是一个新版本了，push发现其他版本了后，再继续merge一个版本出来。
总有一天可以push上去的。
这个问题应该分两种解决方法： 第一种：应该是只有版本差异过大的时候，才必须先pull + merge才能push。但是你merge之后，版本差异不大的时候，可以push。 第二种：每个人应该保持一个自己的分支。先push到自己的分支上，然后再从服务器端merge到master上。
A和B可以商量好，达成一致，都只rebase不merge。这样历史看起来也比较好看，一根线，不乱。
如果出现这样的问题，那说明A、B之间的代码耦合度太多，需要重新分工
既然冲突了就merge呗，一直merge到他和你没冲突就可以push上去啦