[SCM]源碼管理 – GIT

轉自：http://roclinux.cn/?p=2129 + http://roclinux.cn/?p=2115 

 

參考：http://www.nvie.com/posts/a-successful-git-branching-model/

 

一張描述git資料移轉的，很清晰，對於理解git的命令很有協助，轉寄分享在這裡：

 

1 GIT，在技術層面上，絕對是一個無中心的分布式版本控制系統，但在管理層面上，我建議你保持一個中心版本庫。

 

2 我建議，一個中心版本庫(我們叫它origin)至少包括兩個分支，即“主分支(master)”和“開發分支(develop)”

 

3 要確保：團隊成員從主分支(master)獲得的都是處於可發布狀態的代碼，而從開發分支(develop)應該總能夠獲得最新開發進展的代碼。

 

4 在一個團隊開發協作中，我建議，要有“輔助分支”的概念。

 

5 “輔助分支”，大體包括如下幾類：“管理功能開發”的分支、“協助構建可發布代碼”的分支、“可以便捷的修複發布版本關鍵BUG”的分支，等等

 

6 “輔助分支”的最大特點就是“生命週期十分有限”，完成使命後即可被清除。

 

7 我建議至少還應設定三類“輔助分支”，我們稱之為“Feature branches”，“Release branches”，“Hotfix branches”。

至此，我們形成了如下這張最重要的組織組，包含了兩個粗體字分支（master/develop）和三個細體字分支（feature/release/hotfixes）。

 

8 “Feature branches”，起源於develop分支，最終也會歸於develop分支。

 

9 “Feature branches”常用於開發一個獨立的新功能，且其最終的結局必然只有兩個，其一是合并入“develop”分支，其二是被拋棄。最典型的“Fearture branches”一定是存在於團隊開發人員那裡，而不應該是“中心版本庫”中。

 

10 “Feature branches”起源於“develop”分支，實現方法是：git checkout -b myfeature develop

11 “Feature branches”最終也歸於“develop”分支，實現方式是：

git checkout devleop
git merge --no-ff myfeature
（--no-ff，即not fast forward，其作用是：要求git merge即使在fast forward條件下也要產生一個新的merge commit）
（此處，要求採用--no-ff的方式進行分支合并，其目的在於，希望保持原有“Feature branches”整個提交鏈的完整性）
git branch -d myfeature
git push origin develop

 

12 “Release branch”，起源於develop分支，最終歸於“develop”或“master”分支。這類分支建議命名為“release-*”

 

13 “Relase branch”通常負責“短期的發布前準備工作”、“小bug的修複工作”、“版本號碼等元資訊的準備工作”。與此同時，“develop”分支又可以承接下一個新功能的開發工作了。

 

14 “Release branch”產生新提交的最好時機是“develop”分支已經基本到達預期的狀態，至少希望新功能已經完全從“Feature branches”合并到“develop”分支了。

 

15 建立“Release branches”，方法是：

git checkout -b release-1.2 develop
./bump-version.sh 1.2 （這個指令碼用於將代碼所有涉及版本資訊的地方都統一修改到1.2，另外，需要使用者根據自己的項目去編寫適合的bump-version.sh）
git commit -a -m "Bumped version number to 1.2"

16 在一段短時間內，在“Release branches”上，我們可以繼續修複bug。在此階段，嚴禁新功能的併入，新功能應該是被合并到“develop”分支的。

 

17 經過若干bug修複 後，“Release branches”上的代碼已經達到可發布狀態，此時，需要完成三個動作：第一是將“Release branches”合并到“master”分支，第二是一定要為master上的這個新提交打TAG（記錄裡程碑），第三是要將“Release branches”合并回“develop”分支。

git checkout master
git merge --no-ff release-1.2
git tag -a 1.2 （使用-u/-s/-a參數會建立tag對象，而非軟tag）
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2

18 “Hotfix branches”源於“master”，歸於“develop”或“master”，通常命名為“hotfix-*”

 

19 “Hotfix branches”類似於“Release branch”，但產生此分支總是非預期的關鍵BUG。

 

20 建議設立“Hotfix branches”的原因是：希望避免“develop分支”新功能的開發必須為BUG修複讓路的情況。

 

21 建立“Hotfix branches”，方法是：

git checkout -b hotfix-1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bumpt version to 1.2.1" （然後可以開始問題修複工作）
git commit -m "Fixed severe production problem" （在問題修複後，進行第二次提交）

22 BUG修複後，需要將“Hotfix branches”合并回“master”分支，同時也需要合并回“develop”分支，方法是：

git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1

 

完！

 

轉自：http://roclinux.cn/?p=2129 + http://roclinux.cn/?p=2115 

 

參考：http://www.nvie.com/posts/a-successful-git-branching-model/

 

一張描述git資料移轉的，很清晰，對於理解git的命令很有協助，轉寄分享在這裡：

 

1 GIT，在技術層面上，絕對是一個無中心的分布式版本控制系統，但在管理層面上，我建議你保持一個中心版本庫。

 

2 我建議，一個中心版本庫(我們叫它origin)至少包括兩個分支，即“主分支(master)”和“開發分支(develop)”

 

3 要確保：團隊成員從主分支(master)獲得的都是處於可發布狀態的代碼，而從開發分支(develop)應該總能夠獲得最新開發進展的代碼。

 

4 在一個團隊開發協作中，我建議，要有“輔助分支”的概念。

 

5 “輔助分支”，大體包括如下幾類：“管理功能開發”的分支、“協助構建可發布代碼”的分支、“可以便捷的修複發布版本關鍵BUG”的分支，等等

 

6 “輔助分支”的最大特點就是“生命週期十分有限”，完成使命後即可被清除。

 

7 我建議至少還應設定三類“輔助分支”，我們稱之為“Feature branches”，“Release branches”，“Hotfix branches”。

至此，我們形成了如下這張最重要的組織組，包含了兩個粗體字分支（master/develop）和三個細體字分支（feature/release/hotfixes）。

 

8 “Feature branches”，起源於develop分支，最終也會歸於develop分支。

 

9 “Feature branches”常用於開發一個獨立的新功能，且其最終的結局必然只有兩個，其一是合并入“develop”分支，其二是被拋棄。最典型的“Fearture branches”一定是存在於團隊開發人員那裡，而不應該是“中心版本庫”中。

 

10 “Feature branches”起源於“develop”分支，實現方法是：git checkout -b myfeature develop

11 “Feature branches”最終也歸於“develop”分支，實現方式是：

git checkout devleop
git merge --no-ff myfeature
（--no-ff，即not fast forward，其作用是：要求git merge即使在fast forward條件下也要產生一個新的merge commit）
（此處，要求採用--no-ff的方式進行分支合并，其目的在於，希望保持原有“Feature branches”整個提交鏈的完整性）
git branch -d myfeature
git push origin develop

 

12 “Release branch”，起源於develop分支，最終歸於“develop”或“master”分支。這類分支建議命名為“release-*”

 

13 “Relase branch”通常負責“短期的發布前準備工作”、“小bug的修複工作”、“版本號碼等元資訊的準備工作”。與此同時，“develop”分支又可以承接下一個新功能的開發工作了。

 

14 “Release branch”產生新提交的最好時機是“develop”分支已經基本到達預期的狀態，至少希望新功能已經完全從“Feature branches”合并到“develop”分支了。

 

15 建立“Release branches”，方法是：

git checkout -b release-1.2 develop
./bump-version.sh 1.2 （這個指令碼用於將代碼所有涉及版本資訊的地方都統一修改到1.2，另外，需要使用者根據自己的項目去編寫適合的bump-version.sh）
git commit -a -m "Bumped version number to 1.2"

16 在一段短時間內，在“Release branches”上，我們可以繼續修複bug。在此階段，嚴禁新功能的併入，新功能應該是被合并到“develop”分支的。

 

17 經過若干bug修複 後，“Release branches”上的代碼已經達到可發布狀態，此時，需要完成三個動作：第一是將“Release branches”合并到“master”分支，第二是一定要為master上的這個新提交打TAG（記錄裡程碑），第三是要將“Release branches”合并回“develop”分支。

git checkout master
git merge --no-ff release-1.2
git tag -a 1.2 （使用-u/-s/-a參數會建立tag對象，而非軟tag）
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2

18 “Hotfix branches”源於“master”，歸於“develop”或“master”，通常命名為“hotfix-*”

 

19 “Hotfix branches”類似於“Release branch”，但產生此分支總是非預期的關鍵BUG。

 

20 建議設立“Hotfix branches”的原因是：希望避免“develop分支”新功能的開發必須為BUG修複讓路的情況。

 

21 建立“Hotfix branches”，方法是：

git checkout -b hotfix-1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bumpt version to 1.2.1" （然後可以開始問題修複工作）
git commit -m "Fixed severe production problem" （在問題修複後，進行第二次提交）

22 BUG修複後，需要將“Hotfix branches”合并回“master”分支，同時也需要合并回“develop”分支，方法是：

git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1

 

完！