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

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

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

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

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

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

在合并之前，記得要先更新合并分支的代碼，避免出現提交的曆史不匹配，而導緻更多的沖突。

git最佳分支流程

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

一般開發環境中，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狀态：

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

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

歡迎關注我【居家程序員】

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

我并不是高冷（Git進行中01）：git基本流程簡介可以說是矯情暖男（Git進行中02）：git基本操作想獨立門戶嗎（Git進行中03）：Git分支介紹

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!