技術團隊代碼分支管理指南

該篇文章最早發表在 LeanCloud 開發資源

介紹

這是我們團隊的 Git 分支管理規范。每個人對工具的使用往往各有偏好，各種方法各有利弊，無所謂對錯。但涉及團隊協作的方面需要有一些一致的規范，所以請大家務必遵守。

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

• 確保可以輕易確定特定時間發布或運行的版本。在新發布的程序存在重大缺陷時，可以盡快 rollback 到上一個穩定版本。

• 在需要修復緊急 bug 并盡快發布時，可以只發布必要的 bugfix 而不同時發布還不應發布的其他改動。

branch 和 tag

每個官方的 repo（leancloud/ 下的都是官方 repo）有且僅有以下的 branch 和 tag。

Branch: master 和 release。其中 master 對應目前的開發分支，所有的 pull request 都應該發到這個分支。release 是當前發布的分支，在這個分支只能增加從 master cherrypick 過來的 commit。詳見本文后面的說明。

Tag: 對應每個發布版本的 tag。SDK 和應用程序的 tag 遵照 <major>.<minor>.<patch> 的命名，如 2.5.1；服務端程序的 tag 以發布的日期命名，如 2014.11.13，如果有 bugfix，則在后面增加小寫字母，如 2014.11.13 后是 2014.11.13a，然后是 2014.11.13b。

目前還有部分 repo 包含多個獨立部署的項目（如 uluru-platform）。在這樣的 repo 打 tag 時需要附上項目名做前綴，如 bigquery-2.5.1。但我們需要逐步把這些項目拆分到獨立的 repo。

發布新版流程

• 確保所有要發布的 pull request 都已經 merge 到 master；

• 使用 master branch 的代碼進行測試，如果發現 bug，把對應的 bugfix merge 到 master；

• 刪除舊的 release branch，并從當前的 master 創建新的 release branch；

• 在 Jenkins 上從 release branch 發起新的 build 并發布；

• 發布完成后在當前的 release branch 打上對應版本的 tag。

Bugfix 流程

這里的 bugfix 指的是修復已經發布的程序（release branch）中的缺陷。master 里的 bug 請直接 merge bugfix 到 master。

• 如果此缺陷在 master 中還存在，請先 merge bugfix 到 master，否則跳到下一步；

• 在 release branch 從 master cherrypick 修復該缺陷的一個或多個 commit；

• 在 Jenkins 上發布當前 release branch；

• 發布完成后在當前的 release branch 打上遞增的 tag。比如，如果上一個 tag 是 2.5.1，這個 tag 應該是 2.5.2；如果上一個是 2014.11.13，這個就是 2014.11.13a。

其他

并不是每個 bug 都有專門發布 bugfix 版的必要，對于不緊急的 bug，可以在 master 里 fix 后隨下一個版本發布。

在一個官方 repo 下只應該有以上說的 branch 和 tag，在開發過程中使用到的 feature branch 等請都放在個人的 fork，一律通過向 master 發 pull request 的方式給官方 repo 提交代碼。介紹