合併分支可謂是分支操作中最為繁瑣、最容易出現問題的環節。

但有些人會有疑問，一定要在其他分支上開發，開發完成再合併到主分支上嗎？那如果多人協作的情況怎麼辦？不會出現問題嗎？

在開發中，我們一般不會直接對主幹進行修改，而是從開發分支，如dev分支中，創建自己的分支，在分支上進行修改。

在我的理解中，是為了保證主幹上代碼的乾淨。

保證了主幹上的代碼是可以直接發佈或者被項目之外的人使用（例如新入職的員工，總不能給人家一個一運行就報錯的代碼庫吧）。然後關於產品/項目的新特性和BUG修改都在不同的分支上進行開發和測試。這樣規範了整個軟件的開發流程。分支之間的互不影響這種特性可以增加團隊合作的效率。

至於多人協作時出現的各式各樣的問題，歸根到底只需要記住一個點，就能大量避免遠端上的問題，那就是！

在合併之前，記得要先更新合併分支的代碼，避免出現提交的歷史不匹配，而導致更多的衝突。

git最佳分支流程

接下來，我們就基於前面幾篇，來進行一個完整的開發流程：

這篇沒有H1標題了！

一般開發環境中，git會存在master主分支、release發佈分支、dev開發分支，甚至還有test測試分支。

以下基於存在master主幹分支、dev開發分支的情況下進行，若沒有dev分支，那麼建議你說服你的技術主管（我相信你可以的）

1、從遠端clone項目到本地後，先切換到dev分支並在該dev分支上更新下最新代碼，保證待會創建的分支的代碼都是最新的：

 git pull

2、開分支：

 git branch feature-2019-6-29-testBranch

feature一般用於新功能開發

feature命名的分支，我們一般用於新功能的開發，它只與dev分支交互，開發完成併合併到dev後，就會刪除該分支。

另外還有hotfix命名的分支，一般用於修復主幹分支上的bug，但需要注意，由於該bug是舊版本所存在的問題，那麼在dev分支上也同樣存在該問題，也就代表著，修復了這個bug後，該hotfix分支的提交需要合併到master和dev兩個分支上，避免後續dev分支合併master分支時出現問題。

而dev分支將作為最終開發和調試的代碼庫，完成後合併master分支，併發布新版本。

3、查看分支情況（以及自己正在使用的分支）：

 git branch

4、切換分支：

 git checkout featrure-2019-6-29-testBranch

5、查看分支情況（是否有提交之類的）：

總結下上面的步驟：

1、上面的步驟可以直接通過一個命令來進行創建分支，並切換分支：

 git checkout -b feature-2019-6-29-testBranch

2、在該分支上進行修改，修改完後進行添加和提交：

 git add .
 git commit -m "備註"

3、本地切換為dev分支，更新下dev為最新（因為可能其他開發人員已經合併過代碼，此時你本地的dev不再是最新），為了下面的合併不受衝突：

 git checkout dev
 git pull

4、切換回來

 git checkout feature-2019-6-29-testBranch

5、將更新到最新dev合併到自己這個分支上，這一步是為了在你修改自己的分支的過程中，已經有分支合併到dev上了，如果有衝突的話，就先把dev的合併過來，然後在分支上進行衝突解決：

 git merge dev

注意，當前分支為要被合併的分支

6、如果merge後有衝突需要修改，修改後進行 添加、提交、拉取最新（如果這個分支別人也有修改，記得pull更新最新，確保不衝突）：

 git add .
 git commit -m "備註"
 git pull orgin feature-2019-6-29-testBranch

7、確認無誤後，保證編譯正常的情況下，就可以push這個分支到遠程倉庫了：

 git push origin feature-2019-6-29-testBranch

8、之後就可以在dev分支上合併自己的那個分支了（但項目不受權限控制，可以直接通過命令來合併）：

 git checkout dev
 git merge feature-2019-6-29-testBranch
 git pull
 git push dev

注意，需要先切換當前分支為要被合併的分支，如此時是dev分支。

9、當沒有權限對dev進行操作的時候，則需要在頁面上進行合併的操作（以GitLab為例）：

提交合並請求，給到有權限的人，去確定合併

10、至此分支操作結束，刪除分支，刪除分支的時候需要先切換分支為其他分支，才能進行刪除：

刪除本地分支：

 git branch -d feature-2019-6-29-testBranch

刪除遠程分支：

 git push origin --delete feature-2019-6-29-testBranch

當出現衝突的時候：

1、主幹版本有新的提交，分支上也同樣修改了該文件，此時在主幹上pull更新到最新，然後checkout到分支上，合併主幹的時候，會出現

這種情況，可以先將本地的修改存儲到暫存區：

然後再合併：

再把自己的修改從暫存區拿出來：

（git stash list： 可以看到暫存區裡面的東西，從而可以根據需要來獲取

git stash pop: 把暫存區裡面的修改取出來

git stash clear：清除暫存區 ）

這時候，文件會變成conflict狀態：

修改後，再提交，再合併回主幹，就不會有衝突了。

是不是真的沒有H1標題

總的來說，一般開發過程中，都有一個前提，那就是不會直接使用master分支進行開發，而是由dev分支進行，有些團隊在這個基礎上，讓各個開發人員都使用自己的dev分支，也就是說會有很多個dev分支（如dev_某某某），開發人員在開發完成，解決完衝突後，再將自己的分支合併到主開發分支（可能會使用dev分支，或者也可能會使用release發佈分支）上，各自維護各自的開發分支。

後續

使用分支+merge開發，是Git在開發中最常見的開發方式，但由於每次合併都會使用merge，在本地分支的提交歷史和遠端的分支的提交歷史不一致的情況下，此時Git會為我進行了自動合併，然後生成了一個新的提交歷史，內容如“merge branch 'master' of...”，也就是產生了分叉，若不想看到這種情況，我們就會使用另一個命令git rebase來進行，該命令可以使分支間的提交歷史同步，不會產生分叉，我們後面再來說。