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

該篇文章最先發表在 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 提交代碼。介紹