Git使用規範 Android 版

根據 Git 分支管理策略，結合 Git Flow 分支管理實踐，以及 Android 實際開發狀況，制定了這個適合 App 項目開發的 Git 使用規範 。

1、Git的⼏個理念

1. 分支

Git 的 master 分支並非⼀個特殊分⽀，它與其它分⽀沒有任何區別。之因此幾乎每⼀個倉庫都有 master 分支，是由於 git init 命令默認建立它，而且⼤多數⼈都懶得去改動它。

2. 分支與合併

在 Git 中分支合併是很日常的事情，在開發過程當中要適應常常進行分⽀合併的操做。在Git中，分⽀只是一個指針，並不會進⾏物理拷貝，因此建立分⽀時異常⾼效與易用。

3. 徹底分佈式

雖然都有⼀個 Git 服務器，即 origin ，實際上它與每一個開發人員本地倉庫是平等的。 origin 主要⽤於永久保存代碼，同時也便於開發人員之間協同工做。但從技術上來講， origin 與開發人員的本地倉庫沒有什麼不一樣。

2、Git分支模型

分⽀模型，是對 Git 運用的⼀種約束，適配於團隊的⽇常開發、新功能開發、bug修復；經過該模型以建⽴一套⾏之有效的開發、測試及上線發佈流程。同時，分支模型約定全部的開發⼈員的操做規範，創建對應的處理流程，使得軟件的開發過程更易於管理。

1. master分支

git 的默認分⽀，主分支，不輕易改動，上面的代碼爲生產環境的最新發布版本。在新版本發佈後，須要將新版本代碼合併到該分支，並在該分支上打 tag 。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
-	-	develop fix-*	release-* fix-*	-	⽆ Push 權限	生產

2. develop分支

一般建立 git 項⽬的同時就建立 develop ，是開發人員⽤的主要分支，以 master 爲分⽀來源。其最新代碼表明着開發⼈員爲下一個發佈版本提交的最新代碼。不能表明最新的特性代碼，也不表明正在發佈的版本代碼。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
-	master	feature-* release-*	feature-* release-* fix-*	-	⽆ Push 權限	-

禁⽌將下列分⽀合併入 develop 分支：

• 新功能未完成的 feature 分⽀；
• 測試環境未經過的 release 分支；
• 問題未修復的 fix 分支。

3. feature分⽀

feature 分支，即新功能分支(有時也稱之爲特性分支)，主要被用於即將開發的或更長期的功能開發。

它有可能被合併到 develop 分支或者被廢棄掉。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
feature-AppVersion feature-AppVersion-DeveloperName	develop	-	-	develop	all	開發

feature 分支的建立規則取決於需求複雜程度和開發人員數量，須要考慮開發效率、衝突出現的頻次和解決衝突須要花費的時間和精力。

若是需求相對簡單或者開發人員較少，可使用一個分支進行開發，命名規則採用 feature-AppVersion ，示例：feature-1.0.0。

若是需求相對複雜或者開發人員較多，建議每個開發人員一個分支，命名規則採用 feature-AppVersion-DeveloperName，示例：feature-1.0.0-zhangsan。

4. release分⽀

release 分支專供測試使用，容許咱們在發佈前，作最後⼀點改動，包括少許BUG的修改、元數據(如版本信息、編譯參數等)的修改等。當全部⼯做完成後， develop 分支再將這些修改所有合併回來，開始下⼀個版本的開發⼯做。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
release-AppVersion	develop	-	-	develop master	Push 權限	測試

命名示例：release-1.0.0。

5. release-fix分⽀

release-fix 分⽀⽤於修復當前 release 分⽀的 bug。

release-fix 分⽀可由某開發人員建立，而且推送到 origin，可由多位開發者共同修復各⾃開發代碼產⽣的 bug。每次修復完bug，直接打包給測試，測試經過後，發送 MR 請求到 release 分支。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
release-fix-AppVersion	release-AppVersion	-	-	release-AppVersion	all	開發/測試

命名示例：release-fix-1.0.0。

6. fix分支

fix分支用於解決生產環境發現的BUG。

當生產環境發現BUG後，基於最新一次發佈App的版本號，建立 fix 分支進行BUG修復。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
fix-AppVersionc	master	-	-	develop	all	測試/生產

規範命名的 count 爲該版本發現

7. optimize分支

優化代碼分支，若是項目中使用的某個技術已通過時，或者隨着技術的提高，感受以前的代碼有更好的實現，在時間容許的狀況下，能夠考慮優化該部分代碼。考慮到新代碼可能出現BUG，通過嚴格測試後，才容許合併到 develop 分支，不然僅僅做爲我的技術練習。

命名規範	分支來源	分支目標	合併來源	合併目標	權限	應用環境
optimize-content	develop	-	-	develop	all	開發

命名規範中的 content 爲準備優化的地方，例如：optimize-layout-layer。

feature 分支 和 optimize 分支區別：feature 分支靠需求驅動，optimize 分 靠技術驅動。

fix 分支 和 optimize 分支區別：fix分支必定會在下一個版本上線，而 optimize 分支不必定在下一個版本上線。

3、Git使用流程

1. 建立項目

1. 在 Gitlab 上建立項目，將項目拉取到本地。

2. 建立如下文件：

   • README.md ：工程說明；
   • CHANGELOG.md：變動說明日誌，記錄每一個版本作的事情，相似於應用市場上發佈的版本說明；
   • .gitignore：配置不須要 Git 進行管理的文件。
3. 將修改提交到遠程，這個時候Git 會默認建立 master 分支。
4. 基於 master 分支建立 develop 分支。

2. 新功能開發

1. 基於 develop 分支建立 feature 分支。
2. 按照需求和UI完成開發任務。
3. 聯調代碼，完成自測。
4. 若是本次開發建立了多個 feature分支，將其合併到一個 feature 分支上，若是隻是一個 feature 分支，則不進行操做。
5. 拉取 develop 分支上的代碼到 feature 分支，若是存在衝突，解決衝突。
6. 提交 MR 到 develop 分支，MR 經過後刪除 feature 分支。

3. 測試新功能

1. 檢查 MR 到 develop 上的代碼，確認後，贊成 MR。
2. 基於 develop 分支建立 release-version 分支，修改應用 versionCode 和 versionName，更新 CHANGELOG.md 文件中的說明日誌。
3. 在 release-version 上打測試環境的安裝包，提交給測試人員進行測試。
4. 若是測試人員發現BUG，基於 release 建立 release-fix 分支修復BUG，BUG修復後直接在 release-fix分支打測試環境的安裝包，提交給測試人員進行測試。
5. 重複步驟4，直到測試經過。
6. 提交 MR 到 release 分支，MR 經過後刪除 release-fix 分支。

4. 發佈新版本

1. 基於 release 分支打正式包，提交到應用市場。
2. 提交 MR 到 master 分支，贊成後，在 master 分支上打對應版本的 tag，tag的命名規則爲 v + version，示例：v1.0.0。
3. 提交 MR 到 develop 分支，MR 經過後刪除 release 分支。

5. 修復線上BUG

1. 基於 master 分支，使用最新一次發佈App的版本號，建立 fix 分支進行BUG修復。
2. BUG修復後直接在當前分支打測試環境的安裝包，提交給測試人員進行測試。
3. 測試未經過，繼續修復。
4. 若是須要當即發版，則基於 fix 分支建立 release 分支，修改應用 versionCode 和 versionName，更新 CHANGELOG.md 文件中的說明日誌，刪除 fix 分支，剩餘步驟參考4. 發佈新版本完成發版。

   若是不嚴重，則提交 MR 到 develop 分支，MR 經過後刪除 fix 分支。

6.優化代碼

1. 基於 develop 分支，建立 optimize 分支。
2. 完成優化。
3. 測試優化。
4. 提交 MR 到 develop 分支，MR 經過後刪除 optimize 分支。

4、提交規範

Git 每次提交代碼，都要寫 Commit message（提交說明），不然就不容許提交。通常來講，commit message 應該清晰明瞭，說明本次提交的目的，包括：代碼做用的位置、代碼變更的類型、簡要描述代碼的功能。

變更類型	描述
feat	新功能（feature）
fix	修復bug
docs	文檔的變更，註釋的變更
style	代碼格式的變更，好比：方法順序、字段順序、方法命名、字段命名等。
refactor	對已上線代碼進行優化，不涉及到需求，只是從技術上去優化代碼
test	測試的變更
chore	構建過程、輔助工具、編輯器配置的變更

示例：

fix(首頁)：修復緩存異常
feat(用戶)：新增修改用戶頭像的功能

注意：每次提交代碼前，應該先執行 pull 拉取服務器最新代碼，防止提交的代碼有衝突。

並且若是先建立本地提交，而後在執行更新操做，這樣會致使 Git 自動生成一個合併提交，致使提交歷史不夠簡潔。

5、MR使用規範

1. MR使用流程

本示例基於 Gitlab。

1. 建立MR請求

1.在項目的倉庫主頁中找到Create Merge request

2.填寫請求內容

注意Title和內容的的填寫規範：可參考MR註釋規範，確認分支來源、目標分支和委託人不要填寫錯誤。

分支說明：

2. 處理MR請求

Gitlab 會經過郵件通知到委託人，處理 MR。

1.查看 MR 中代碼改變了哪些。

2.確認沒有問題，經過 MR，合併完成。若是發現有問題，則關閉請求，合併失敗，須要請求人修改代碼後從新MR.

2. MR註釋規範

全部的 MR 請求者，須要詳細說明提交註釋，以下:

源分支	目標分支	註釋Title	Descrition
release	master develop	release-version 測試已經過，提交發布 示例：release-1.0.0 測試已經過，提交發布	-
feature	develop	feature-version 完成全部功能的開發並聯調經過，提交測試 示例：feature-1.0.0 完成全部功能的開發並聯調經過，提交測試	-
fix	develop（線上Bug下次發版）	fix-version 修復瞭如下bug並測試經過，提交合並fa'bu 示例：fix-1.0.0 修復瞭如下bug並測試經過，提交合並	1. bug1 2. bug2 3. bug3
fix	master（線上Bug當即發版）	fix-version 修復瞭如下bug並測試經過，提交發布 示例：fix-1.0.0 修復瞭如下bug並測試經過，提交發布	1. bug1 2. bug2 3. bug3
release-fix	release	release-fix-version 修復瞭如下bug並測試經過，提交發布 示例：release-fix-1.0.0 修復瞭如下bug並測試經過，提交發布	1. bug1 2. bug2 3. bug3

6、代碼評審

在兩個及兩個以上開發人員的項目中，應該進行代碼評審，檢查代碼風格和是否有潛在的BUG。

考慮到開發時間，MR時須要作簡易 Code Review，項目發佈後作詳細 Code Review，若是須要調整代碼，新建優化分支進行調整，具體流程參考優化代碼

7、經常使用Git命令示例

1. 建立分支

這裏以在本地建立 feature 分支舉例，其餘分支建立須要注意是基於哪一個分支建立，同事還須要注意分支命名規則。

// 切換到 develop 分支
git checkout develop

// 基於 develop 分支建立 feature 分支
git checkout -b feature-1.0.0 

// 將 feature 分支推送到遠程
git push origin feature-1.0.0:feature-1.0.0

// 設置本地 feature 分支關聯遠程 feature 分支
git branch --set-upstream-to=origin/feature-1.0.0 feature-1.0.0

2. 刪除分支

// 刪除本地分支
// 通常刪除，若是分支上的代碼沒有合併，會失敗
git branch -d feature-1.0.0 
// 強制刪除
git branch -D feature-1.0.0 

// 刪除遠程分支
git push origin --delete feature-1.0.0
// or
git push orgin :feature-1.0.0 //（origin 和冒號之間是有空格的）

3. 更新代碼

git pull --no-rebase

4. 添加Tag

// tag 通常在 master 分支添加，因此先切換到 master 分支
git checkout master
// 添加 tag
git tag -a v1.0.0 -m 'tag描述，通常來講就是一句話描述新增代碼的功能'

8、注意事項

1. 避免代碼衝突

爲了儘可能避免衝突發生，養成以下開發習慣：

• 編碼前先更新
• 提交前先更新
• 修改了公共文件，儘早通知其餘成員更新
• 須要提交 MR 到目標分支，先將目標分支的代碼拉到當前分支，若是有衝突，先解決衝突再 MR，沒有衝突則直接提交MR。
• 最後一條，也是最重要的，團隊分工要明確

2. 更新代碼使用Merge而不是Rebase

這裏不使用 rebase，緣由是會把當前分支的 commit 放到公共分支的最後面，因此叫變基。就好像你從公共分支又從新拉出來這個分支同樣，改變了commit 的實際提交順序，這樣其餘從這個公共分支拉出去的人，都須要再 rebase。

1. 使用命令行更新代碼

git pull --no-rebase

2. 使用Android Studio更新代碼

按下圖配置更新選項：

補充：

Update Type 類型：

• Merge：更新時執行合併操做。等價於執行git fetch && git merge或者git pull --no-rebase。
• Rebase：更新時執行rebase操做。等價於執行git fetch && git rebase或者git pull --rebae。
• Branch Default：在.git/config文件中指定不一樣分支的更新類型。

寫在最後
這個版本是團隊最終統一規範時進行了精簡後造成的版本，初始版本中總結了更詳細的用法及注意事項，具體請：點擊前往