git的合併分支包括合併遠端分支和合併本地分支，其實本意是一樣的。只不過拉遠端分支的時候多了一步git fetch，就是把所有分支的**從雲拉到本地快取，但是不做合併。關鍵是合併，說到合併的時候就要說到這最糾結的兩兄弟了。
git merge全稱其實是git merge --ff, ff 就是fast forward。
在當前分支沒有任何提交的情況下，它的指標著被合入分支的提交線一路下去可以走到被合入分支上，就像是指標快進到另乙個分支上，它就像是快進一樣，它不會產生任何merge commit，沒辦法查到合入的記錄。(下右圖所示)
如果在上述情況下，要知道合入的細節，那就要用git merge --no-off。(如上左圖所示)
它的作用就是把被合入分支的詳細提交情況都顯示出來，然後在最後產生乙個merge的新commit。我們就可以清楚的看見這次的merge是怎麼來的。
總結下，ff是head最終指向被合入分支的最後一次提交，而no-ff是指向他們的合入。這種情況下，多說一句，如果要reset，這兩種方式的reset也是不同，ff方式的reset因為沒有快進，所以是回到了被合入分支的commit點(並不是本分支的)，而–no-ff才是真正回到了當前分支的上乙個提交點。
以上這種情況有前提的，前提是當前分支無任何提交。下面這種情況是我們絕大多數的merge情況。
在兩個分支的最近公共點都有新的提交，這樣git merge會將兩個分支的最後節點做合併產生新的節點，並且生成乙個merge的commit記錄。它是嚴格按時間線記錄了分支的提交記錄，方便查詢。但是缺點是在提交線上會分叉，很亂，而且不能直觀的看到你的分支和目標分支的差距。
參考了很多的部落格，rebase用變基是比較準確的。但是要遵守rebase**法則，no one shall rebase a shared branch.
rebase是先刪除當前分支的提交，然後把被合入分支的所有提交都複製到本分支上，再順著提交線把剛才刪除的本分支提交重新生成一下基於這個之上，所以稱為「變基」。rebase的本意是讓當前的開發分支保持在乙個基準上，這樣在提交線上可以看到我們和主分支的head在哪個位置，而且可以把我們領先未合入的提交顯示在最上面，整個過程不會產生merge的記錄，所以自然也不會按時間線顯示提交記錄。
另外rebase可以壓縮commit請求，在提pr時候，可以git rebase head～壓縮commit。
對於這兩個命令我也難以清楚的分清界限，但凡是存在的肯定是合理的。我認為還是取決於專案的使用和管理，分享下我平時的使用。
從遠端同步到master使用git pull --no-ff，清晰的記錄每個人的提交和合入記錄。
在feature分支合併是用git rebase master，讓自己的提交線變得簡單。但如果是共同分支開發，使用merge。
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...