Git工作流及釋出規範（App）

首發於fxm5547的部落格

參考

• open.leancloud.cn/git-branch-…
• blog.coding.net/blog/featur…
• blog.coding.net/blog/git-wo…
• blog.coding.net/blog/princi…

介紹

本約束規則適用於所有iOS和Android工程程式碼。管理工具使用Coding.net提供的git託管服務。

Git的workflow有多種，各有利弊，無所謂好壞。但團隊協作需要有一致的規範，所以請大家務必遵守。

除了一致性之外，這個規範的目的是以下幾點：

• 方便開發和測試同學協同，高效完成研發工作，產出高質量的成果。
• 在需要修復緊急 bug 並儘快釋出時，可以只發布必要的 bugfix 而不同時釋出還不應釋出的其他改動。

branch和tag

使用Feature Branch Workflow，按照需求新建feature branch

Branch: feature branch、master 和 release。master是預設分支，release 是用於釋出的分支。

• feature branch: 功能開發或bug修復從master新建一個分支，push到遠端倉庫，提交合並至master的請求，合併後刪除該分支。
• master: 只負責合併各feature branch的程式碼，且保證master分支隨時處於可測試，測試之後可釋出狀態。 提交後自動觸發整合。
• release: 是當前釋出的分支，在這個分支只能從master新建 或 增加從 master cherrypick 過來的 commit。

Tag: 對應每個釋出版本的 tag。

• SDK 和App應用程式的 tag 遵照 <major>.<minor>.<patch>的命名，如 2.5.1，參考SemVer；
• 服務端程式的 tag 以釋出的日期命名，如 2016.07.28，如果有 bugfix，則在後面增加小寫字母，如 2016.07.28 後是 2016.07.28a，然後是 2016.07.28b。

  

  branch&tag

程式碼提交應儘量採用原子性的提交，即基於單一功能的提交（worktile單一任務或其拆分出的功能），不建議一次性提交多個功能，必須保證每次提交都是可執行的完整功能。提交時必須寫清晰的提交日誌。

開發測試流程

• 開發測試流程

  

釋出管理

所有版本釋出前，測試工程師必須確認測試已完全覆蓋並通過。

• 釋出新版流程：刪除舊的 release branch，並從當前的 master 建立新的 release branch；
• Bugfix 流程： bugfix 指的是修復已經發布的程式（release branch）中的缺陷。在 release branch 從 master branch cherry pick 修復該缺陷的一個或多個 commit；

釋出新版本詳細步驟

1. Coding上刪除release分支；
2. Coding上從master分支新建release分支；
3. 從release分支打包供整合測試後釋出；
4. 在Coding上基於release分支打tag，新增更新日誌。

釋出補丁詳細步驟

1. 先update整個工程；
2. git切換到release分支；
3. 執行 git cherry-pick commit_id 命令；
4. push到遠端release分支；
5. 從release分支打包供整合測試後釋出。
6. 在Coding上基於release分支打tag，新增更新日誌。

其他

• 並不是每個 bug 都有專門釋出 bugfix 版的必要，對於不緊急的 bug，可以 fix 後隨下一個版本釋出。
• master分支和release分支只有負責人有readwrite許可權，其他開發人員只有read許可權。