理解核心
git最初只有乙個分支，所有後續分支都是直接或間接的從這個分支切出來的。
在任意兩個分支上，向前追溯提交記錄，都能找到乙個最近的提交同時屬於這兩個分支，這個提交就是兩個分支的分叉節點
分支合併，就是把其它分支相對於分叉節點發生的變化合併到當前分支中。
git合併(merge)的是變化！
假設情景
時間點1：兩個分支master和dev，現在這兩個分支完全一樣，處在同乙個提交(commit)上，內容含a、b、c、d四部分。
時間點2：dev上開發新內容，不斷修改提交，最後dev分支的內容是a、b'、d、e。修改b為b'，刪除內容c，新增內容e。
時間點3：master分支發現bug，在該分支修改bug並提交，最後master分支內容是a、b''、c、f。修改內容b為b''，修改內容c為c，刪除內容d，新增內容f。
時間點4：此時，如果把master分支合併到dev分支上，master和dev上的內容是什麼呢？
合併過程
git checkout dev # 切換到dev分支git merge master # 合併master分支
合併merge做的幾件事兒：
1、在dev上刪除d，新增f。
這是master分支在時間點3上相對於時間點1發生的部分變化，d在dev分支上沒有變化過，f相對於dev是新內容，合併時沒有衝突，可直接合併。
2、c上產生衝突，該衝突是"修改、刪除"兩種不同動作引起的。
時間點2上dev刪除了c，時間點3上master修改了c，刪除和修改的物件都是同乙個c。相對於時間點1，產生了不一致的變化，無法直接合併。
3、b上產生衝突，該衝突是內容變化後不一致引起的。
時間點2上dev修改b為b'，時間點3上master修改b為b''，修改後b內容不一致。相對於時間點1，也是產生了不一致的變化，無法直接合併。
merge遇到無法合併的衝突(conflict)時，會先記錄下衝突資訊，然後跳過衝突繼續合併後面的內容，直至合併完所有可以合併的內容後，只剩下無法合併的衝突。此時，merge再也無法繼續執行了，只能被迫中斷。中斷前merge做了最後一件事兒，就是在dev分支上標識出衝突資訊，提示使用者需要解決衝突，然後再自行完成merge後面的操作——提交合併後的新commit到版本庫。
如果合併過程順利，是不會產生衝突的，merge就可以在合併完成後，自行提交新commit到版本庫。
這種合併方式是真實的合併(true merge)，合併後會在dev分支上產生乙個新的commit。還有一種合併方式是快進合併(fast-forward merge)，這種方式不會產生新的commit。
解決衝突
1、刪除c
2、修改b為正確內容b'''
3、解決衝突後，提交乙個新的commit
至此，分支內容如下：
master：a、b''、c、f（master是被合併的，所以自己的內容不會變化）
dev：a、b'''、e、f（合併了master在時間點3上相對於時間點1發生的所有變化，並解決了衝突，生產了新commit）
git合併分支
應該是基本知識的,但是之前工作很少用develop分支,用的時候也不會負責合併和發布新版本,所以就一直沒有接觸這塊,做自己小東西一點一點嘗試吧,也不敢亂來,怕一不小心把自己 搞沒了.需求 我在github有乙個master分支,本地有乙個develop分支,目前做的修改都在develop上,現在準備...
git合併分支
工作中很多情況下都是並行開發，後開發的模組上線時需要合併先開發完成的 這就用到了git的多分支合併。這裡以分支dev5.0.1 dev5.0.2和主幹master進行講解。合併思路是先將dev5.0.1合併到master，在dev5.0.2合併master 的 最後把 dev5.0.2 推送到遠端版...
git 合併分支
master 分支 是原來分支 dev 是開發後的分支 現在的任務是要把開發後的dev分支 合併到master上面去 下面開始實戰。首先，我們建立dev分支，然後切換到dev分支 git checkout b dev switched to a new branch dev git checkout...