一般在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上去啦