介紹一個成功的 Git 分支模型(2)_開源配置管理工具

介紹一個成功的 Git 分支模型(2)

發表于：2013-04-02來源：伯樂在線作者：不詳點擊數：標簽：Git

1 2 3 4 5 6 7 8 $ git checkout develop Switched to branch develop $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 0

						$ git checkout develop 

						Switched to branch 'develop'

						$ git merge --no-ff myfeature 

						Updating ea1b82a..05e9557 

						(Summary of changes) 

						$ git branch -d myfeature 

						Deleted branch myfeature (was 05e9557). 

						$ git push origin develop

　　–no-ff標志導致合并操作創建一個新commit對象，即使該合并操作可以fast-forward。這避免了丟失這個功能分支存在的歷史信息，將該功能的所有提交組合在一起。比較:

　　后一種情況，不可能從Git歷史中看到哪些提交一起實現了一個功能——你必須手工閱讀全部的日志信息。如果對整個功能進行回退 (比如一組提交)，后一種方式會是一種真正頭痛的問題，而使用–no-ffflag的情況則很容易.

　　是的，它會創建一個新的(空)提交對象，但是收益遠大于開銷。

　　不幸的是，我還沒找到一種方法，讓–no-ff時作為合并操作的默認選項，但它應該是可行的。

　　Release 分支

　　Release分支可能從develop分支分離而來，但是一定要合并到develop和master分支上，它的習慣命名方式為：release-*。

　　Release分支是為新產品的發布做準備的。它允許我們在最后時刻做一些細小的修改。他們允許小bugs的修改和準備發布元數據(版本號，開發時間等等)。當在Release分支完成這些所有工作以后，對于下一次打的發布，develop分支接收features會更加明確。

　　從develop分支創建新的Release分支的關鍵時刻是develop分支達到了發布的理想狀態。至少所有這次要發布的features必須在這個點及時合并到develop分支。對于所有未來準備發布的features必須等到Release分支創建以后再合并。

　　在Release分支創建的時候要為即將發行版本分配一個版本號，一點都不早。直到那時，develop分支反映的變化都是為了下一個發行版，但是在Release分支創建之前，下一個發行版到底叫0.3還是1.0是不明確的。這個決定是在Release分支創建時根據項目在版本號上的規則制定的。

　　創建一個release分支

　　Release分支是從develop分支創建的。例如，當前產品的發行版本號為1.1.5，同事我們有一個大的版本即將發行。develop 分支已經為下次發行做好了準備，我們得決定下一個版本是1.2(而不是1.1.6或者2.0)。所以我們將Release分支分離出來，給一個能夠反映新版本號的分支名。

						$ git checkout -b release-1.2 develop 

						Switched to a new branch "release-1.2"

						$ ./bump-version.sh 1.2 

						Files modified successfully, version bumped to 1.2. 

						$ git commit -a -m "Bumped version number to 1.2"

						[release-1.2 74d9424] Bumped version number to 1.2 

						1 files changed, 1 insertions(+), 1 deletions(-)

原文轉自：http://blog.jobbole.com/34706/

軟件測試 > 開源軟件測試 > 開源配置管理工具 >