這個問題以前我在用SVN的時候就想過，但當時沒想明白，也沒遇到出bug的時候。
現在學習Git，同樣有這個疑問存在，就提出來。
問題：
在合併分支的時候，如果沒有衝突，Git自動合併的程式碼會不會有bug？
因為Git在合併時偵測到的衝突都是編輯上的衝突，例如兩次編輯是否在同一行上，兩次編輯是否有相反的操作（一個增加一個刪除相同的程式碼），顯然，Git並不也無法關心程式碼本身的邏輯。
所以我認為合併之後應該去檢查程式碼的正確性，相當於每次合併之後都需要驗證兩份分支所解決的問題在合併後是否又處於未解決的狀態，以及是否產生了新了Bug ，那這工作量就大了啊？
不知道各位在實際使用上會這麼去檢查嗎？
你如果有百度過，你應該會看到類似的訊息：雖然你的開發是在branch上，但是為了確保不和主幹偏差太遠，需要經常由trunk合併到branch的。
如果一個團隊遵守流程，就不會有太大的問題。
如果有多人編輯同一個程式碼，Git會報出合併衝突，需人為解決衝突，Git無法知道怎麼處理這些程式碼，這是無法避免的。實際多人協作的專案中，大家一般會分模組開發，盡量避免改動同一處文件；更改公共模組前，先更新。
如果合併之後未報衝突，那就是沒有同一處程式碼被多少更改，沒必要去檢查合併的正解性。至於合併的程式碼引入了邏輯上的bug，那就需要review了。
當然能啊，一個功能要用到a b c 三個方法， 分別三個人去改那三個方法（假設三人都不知道別人改了）； 這種情況，git是不會認為是衝突的；但是你還能保證這個功能還是三人各自想要的嘛？
不會，因為git合併有兩種情況，第一：一個檔案裡面，同一段程式碼被兩個人同時改動過，git合併是會報衝突。需要人工合併。第二：如果兩個人改了同一個檔案的不同程式碼段。 git會自動合併。有沒有bug那完全是寫程式碼的人的問題。有bug，合併之後自然有bug。沒有bug，合併之後也不會有bug。不能亂甩鍋！
Git躺著也中槍，奔淚說：我只負責程式碼合併，bug是人寫的啊，這鍋偶不背。 。 。 。 。 。
凡事無絕對，沒有衝突能合併出bug那隻能說你中獎了
這個不叫bug，叫
衝突。解決衝突的方案：使用別人的版本
使用自己的版本
手動合併。
而規避衝突的一個很常用的方法是：修改前，先
pull本地分支，減少衝突幾率額，git只是個版本管理工具，合併程式碼，出現bug，那是你們專案組自己程式碼問題啊，根本就不是git的鍋，你的這個問題，應該可以透過寫測試程式碼來處理。
是有這個可能的，相當於中獎