首先從這張圖開始我今天的git分支的行走情況：一般的git環境，一般包含master分支，dev開發分支，test測試分支，一般都是test通過的程式碼才能放到master中，所有我們的一般開發一個新的功能，都是從master中拉取程式碼，這個程式碼基本和線上的程式碼是一樣的，然後通過建立分支來對程式碼進行開發（git checkout -b 分支名，檢視分支git status或者git branch），然後開發測試完，然後git add 檔案，git commit -m '註釋'，然後切換到dev分支與dev合併（git checkout dev ,git merge 分支名，如果有衝突，然後修改衝突（基本上保持dev上原來的不變把自己改的加上）,注意不切換分支,然後git add ,git commit -m '',最後git pull ，然後推送到遠端dev中git push），這樣就與dev分支合併了，如果自測沒有問題，就該交到測試去測試了，然後需要把分支與test合併，然後我們需要先切換到原分支（也就是自己之前建的那個分支），然後與git status看提交的情況，然後新增修改提交完，切換到test環境，然後與test合併，還是用git merge 原分支名，然後把衝突解決，以test上的程式碼為主（也就是接受test環境），然後衝突解決完，提交，然後推送到遠端，這樣與test的分支合併就結束了。之後就剩與master分支的合併了，這塊一般都是把原分支推送到遠端建立分支，然後在遠端分支合併。這樣一整套流程就結束了。弄完之後我們來看，其實每次一個新的功能都是從master開始，master就是一個個test測試沒有問題的程式碼的集合，其中dev，test都是比master上要新，這樣dev、test就是一個驗證分支功能的過程，驗證通過，才能放到master，也就是這樣一套code管理流程。

      這就是我在新公司新的一週對git的分支合併的體會。歡迎提出其中的問題，謝謝。