Git使用最佳實踐

背景

簡單的文件拷貝加重命名已經能滿足對於常用的版本控制。如初始文件為"文檔1.doc",修改之後的文件為"文檔2.doc",再次修改之後的為"文檔3.doc"，以此類推...

雖然到最後也能達到一個最終版本作為交付版本。但是假如，這份文件後期被兩個人修改，其中一個命名為a.doc，另外一個命名為b.doc，此時需要作為一個交付版本可能就會如下圖所示，讓人抓狂...

針對上述場景，目前市場上有兩套著名的開源版本方案：svn與git。

git優勢

相對svn，git有如下優勢:

• 分佈式管理、所有本地庫包含了遠程庫的所有內容。

• 優秀的分支模型。打分支以及合併分支，機器方便。

• 快速。在這個時間就是金錢的時代，Git由於代碼都在本地，打分支和合並分支機器快速，使用個SVN的能深刻體會到這種優勢。

挑戰

儘管擁有優秀的版本管理工具，但是我們面對版本管理的時候，尤其是大家工作在同一個倉庫上的時候，那麼彼此的代碼協作將會帶來非常大的問題與挑戰，常見問題如下：

• 如何開始一個Feature的開發，而不影響別的Feature？

• 由於很容易創建新分支，分支多瞭如何管理，時間久了，如何知道每個分支是幹什麼的？

• 哪些分支已經合併回了主幹？

• 如何進行Release的管理？開始一個Release的時候如何凍結Feature, 如何在Prepare Release的時候，開發人員可以繼續開發新的功能？

• 線上代碼出Bug了，如何快速修復？而且修復的代碼要包含到開發人員的分支以及下一個Release?

git-flow

根據上章提出的挑戰，目前市場上已經制定一份通用工作流--git-flow。

一個簡化版本的工作流如下圖所示：

縱軸為時間線，橫軸方向為常定義的分支版本。

常定義的分支信息以及常用約束如下（括號後為該分支常用別名）：

• Production 分支(生產分支、線上分支)

也就是我們經常使用的Master分支，這個分支最近發佈到生產環境的代碼，最近發佈的Release， 這個分支只能從其他分支合併，不能直接修改這個分支。

• Develop 分支（開發分支）

這個分支是我們是我們的主開發分支，包含所有要發佈到下一個Release的代碼，這個主要與其他分支合併，比如Feature分支。

• Feature 分支 （功能分支）

這個分支主要是用來開發一個新的功能，一旦開發完成，我們合併回Develop分支進入下一個Release。

• Release分支 （發版分支，待驗收分支）

當你需要一個發佈一個新Release的時候，我們基於Develop分支創建一個Release分支，完成Release後，我們合併到Master和Develop分支。

• Hotfix分支 （維護分支、熱更分支）

當我們在Production發現新的Bug時候，我們需要創建一個Hotfix, 完成Hotfix後，我們合併回Master和Develop分支，所以Hotfix的改動會進入下一個Release。

當然上述僅是一個分支名稱的引用規則，具體名稱可以根據實際場規範約束實際使用的分支名稱。

使用場景

• 初始分支

所有在Master分支上的Commit應該Tag，作為一個短期里程碑。

• Feature 分支

Feature分支開發完成之後，經單元測試，必須合併回Develop分支,。合併完分支後一般會刪除這個線上Feature分支，或者按分支名稱+功能簡碼進行歸檔。

• Release分支

Release分支基於Develop分支創建，創建完Release分支之後，我們可以直接在這個Release分支上測試，修改Bug等。

同時，其它開發人員可以基於開發新的Feature。

一旦打了Release分支之後不要從Develop分支上合併新的改動到Release分支。

發佈Release分支時，合併Release到Master和Develop， 同時在Master分支上打個Tag記住Release版本號，然後可以刪除Release分支了。

通常此版本一般與CI/CD進行整合。一旦開發發佈至此分支，測試與QA等其他部門就可以將此分支形成的應用程序進行分發測試驗證。

• Hotfix分支

hotfix分支基於Master分支創建，開發完後需要合併回Master和Develop分支，同時在Master上打一個tag

具體實踐

• 創建develop分支

git checkout -b develop
git push -u origin develop  

• 開始新Feature開發

git checkout -b some-feature develop
# 通常 一旦創建就將此創建出來的分支推送至倉庫中，方便其他協作者能及時獲取分支名稱，防止多人命名重複。
git push -u origin some-feature 
# 開發代碼修改 
git status
git add some-file #some-file為本次開發的功能模塊具體代碼
git commit

• 完成Feature

git pull origin develop
git checkout develop
# 將某個功能模塊與當前開發分支進行合併，防止出現大規模多人修改衝突。
git merge --no-ff some-feature
git push origin develop
# 此部分也可以不刪除，或者將其按照某種該規則(如feature-xxxx)重命名該分支，並進行歸檔。
git branch -d some-feature
# 通常將倉庫中改功能模塊分支刪除。
git push origin --delete some-feature 

• 開始Relase

# 通常release分支中都含有一個版本號，通常開發合併過來都只修改版本號的最後一位。
# 此部分儘量將修改的功能模塊點標註出來，方便後期做版本更改記錄。
git checkout -b release-0.1.0 develop

• 完成Release

git checkout master
git merge --no-ff release-0.1.0
git push
## 將release分支與開發分支進行合併，方便其他協作者同步當前最新版本
git checkout develop
git merge --no-ff release-0.1.0
git push
git branch -d release-0.1.0
# 【可選】刪除遠程倉庫中的release分支
git push origin --delete release-0.1.0 
# 通常master上的分支為release分支中的版本號+1，表示線上發佈的版本已經進行更新。
git tag -a v0.1.1 master
git push --tags

• 開始熱更線上代碼Hotfix

# 從當前線上分支直接切一個臨時分支作為熱更分支。
git checkout -b hotfix-0.1.1 master 

# 完成修改之後，將熱更修復的代碼合併至線上主分支中。
git checkout master
git merge --no-ff hotfix-0.1.1
git push
# 同時需要將熱更的代碼同步至開發分支中，防止其他協作同事未獲取到最新線上代碼。
git checkout develop
git merge --no-ff hotfix-0.1.1
git push
# 嘗試刪除本地hotfix分支，並創建臨時版本
git branch -d hotfix-0.1.1
git tag -a v0.1.2 master
git push --tags

結束

本次重點闡述的僅是git的一個最佳實踐方案。具體可以根據自家公司已有的命名規則進行自定修改。