通常,合併分支時,如果可能,git會用fast forward模式,但這種模式下,刪除分支後,會丟掉分支資訊。
如果要強制禁用fast forward模式,git就會在merge時生成乙個新的commit,這樣,從分支歷史上就可以看出分支資訊。
下面我們實戰一下--no-ff方式的git merge:
1. 建立並切換dev分支
$ git checkout -b dev
switched to a new branch 'dev'
2. 修改readme.txt的內容並提交
$ cat readme.txt
git is a version control system.
git is free software under the gpl.
git tracks changes.
create a new branch is quick and sample.
git merge --no-ff
$ git add readme.txt
$ git commit -m "add merge"
[dev a382c8e] merge no-of
1 file changed, 1 insertion(+)
3. 切換master分支
$ git checkout master
switched to branch 'master'
your branch is ahead of 'origin/master' by 4 commits.
(use "git push" to publish your local commits)
4. 合併dev分支,請注意--no-ff引數,表示禁用fast forward:
$ git merge --no-ff -m "merge no-ff" dev
merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
5. 檢視合併歷史
$ git log --graph --pretty=oneline --abbrev-commit
* 07dd582 merge no-ff
|\| * a382c8e add merge
|/* 20b4da1 conflict fixed
|\| * 36ac3dc and sample
* | bf81d3e & sample
|/* cd7428c new branch dev
* b0e9ec8 delete test
* 120dab8 add test.txt
* 1161148 tracks change
* 85e468e free software
* a2de034 git init
可以看到,不使用fast forward模式,merge後就像這樣:
在實際開發中,我們應該按照幾個基本原則進行分支管理:
首先,master分支應該是非常穩定的,也就是僅用來發布新版本,平時不能在上面幹活;
那在哪幹活呢?幹活都在dev分支上,也就是說,dev分支是不穩定的,到某個時候,比如1.0版本發布時,再把dev分支合併到master上,在master分支發布1.0版本;
你和你的小夥伴們每個人都在dev分支上幹活,每個人都有自己的分支,時不時地往dev分支上合併就可以了。
所以,團隊合作的分支看起來就像這樣:
分支管理策略
通常,合併分支時,如果可能,git會用fast forward模式,但這種模式下,刪除分支後,會丟掉分支資訊。如果要強制禁用fast forward模式,git就會在merge時生成乙個新的commit,這樣,從分支歷史上就可以看出分支資訊。下面我們實戰一下 no ff方式的git merge 首先...
Git分支管理策略
如果你嚴肅對待程式設計,就必定會使用 版本管理系統 version control system 眼下最流行的 版本管理系統 非git莫屬。相比同類軟體,git有很多優點。其中很顯著的一點,就是版本的分支 branch 和合併 merge 十分方便。有些傳統的版本管理軟體,分支操作實際上會生成乙份現...
Git分支管理策略
git分支管理策略 作者 阮一峰 如果你嚴肅對待程式設計,就必定會使用 版本管理系統 version control system 眼下最流行的 版本管理系統 非git莫屬。相比同類軟體,git有很多優點。其中很顯著的一點,就是版本的分支 branch 和合併 merge 十分方便。有些傳統的版本管...