看你程式碼是怎麼寫的，不一定衝突，第二次提交的時候，你feature2分支的程式碼已經落後於master了（因為feature1先提交了），所以會“程式碼合併”，但合併不一定會衝突，衝突是指git認不出來該怎麼合併，需要你人工介入

除非是兩個開發者同時修改了一個檔案，才會導致衝突。

如果他們開發各自的模組檔案沒有交疊的，那麼就不會衝突。

如果檔案有衝突會有標誌，然後手工解決衝突就可以了。

不一定。是否衝突取決於兩種修改是否會產生歧義。不如第一個patch修改了檔案a的第x行，第二個patch也修改了同一個地方，但是修改內容或者方式不同，那如果一個patch merge進去以後，另一個patch嘗試merge一定會產生衝突。

兩個分支不一定會有衝突，這個取決於你修改的東西。如果兩個分支改到同一個檔案，提交程式碼的時候會提示有衝突。

有衝突解決就可以了，不用太擔心。如果是windows，推薦使用TortoiseGit,解決衝突很方便。

存在衝突的可能。

有衝突很正常，幾個人會同時修改一個檔案，那就解決衝突就好了，不用擔心有衝突。

git本來就是版本管理工具，衝突處理是基本功能。

Git和svn都是比較不錯的程式碼版本控制工具

幾年前svn用的還挺多，現在基本上git是標配了

Git確實很強大很優秀！

誇了一波git後開始進入正題

兩個版本都合併到master分支不一定會產生衝突。

首先產生衝突的本質是git不知道怎麼去合併某一行或多行的程式碼，需要人為的處理告訴它。

說白了就是因為兩個分支在修改了同一個檔案的同一行程式碼的情況才可能出現衝突，哪怕是多了一個空格。

當然如果兩分支程式碼互不影響，合併就沒衝突了。

這裡我想多說兩句，就是我們公司採用的一些不錯的git使用流程規範：

①按照bug，需求任務編號等建立分支名，比如bug110，task666等所謂的feature分支

這樣一看分支就知道這個分支幹嘛用的。缺點就是隨著專案迭代bug和需求越來越多，分支也會很龐大。

我們是會定期清理這些分支來解決這個小缺點。

②然後有一個develop分支，專門給開發環境上用的。

④假如4月16我們上線的東西就是解決bug編號是110的和任務編號是666的，那麼我們會將bug110和task666合併到這個release分支，jenkins構建完測試去測

⑤假如這兩個測試通過了那就直接把這個release分支合併到master，假如有一個沒透過那麼就刪了這個分支重新建一個release分支，把測試透過的功能分支合進去後，最後用新的release合到master

⑥等到上線了把develop分支基於master去rebase一下

基本就這樣，感覺屢試不爽。當然避免不了衝突，但是一般都沒有多大的衝突，很好解決。

上述的編號都是來自禪道或者redmine的。

這種操作太常見了，尤其是使用pr流程的時候，基本每次提交都是這種情況，如果兩條分支的開發目標有重疊，基本上必然會衝突，否則衝突的機會很小，所以要在拉分支切割任務的時候就切分好，避免後面衝突