Git工作流及釋出規範（BED-FED）

fxm547發表於2018-01-23
Git

首發於fxm5547的部落格

參考

介紹

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

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

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

  • 方便開發和測試同學協同，高效完成研發工作，產出高質量的成果。
  • 確保可以輕易確定特定時間釋出或執行的版本。在新發布的程式存在重大缺陷時，可以儘快 rollback 到上一個穩定版本。
  • 在需要修復緊急 bug 並儘快釋出時，可以只發布必要的 bugfix 而不同時釋出還不應釋出的其他改動。

branch和tag

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

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

  • feature branch: 功能開發或bug修復從master新建一個分支，push到遠端倉庫，提交合並至master的請求，合併後刪除該分支；需要多人協作的功能開發，負責人新建分支，共同在該分支上開發，可以測試時提交合並至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. 在伺服器上執行釋出新版本的指令碼

釋出補丁詳細步驟

  1. 先update整個工程
  2. git切換到release分支
  3. 執行git status命令
  4. 執行 git cherry-pick commit_id 命令
  5. 如果遇到衝突，解決衝突，解決衝突的辦法是接受他們的程式碼，解決衝突後commit file && push file，如沒遇衝突則直接push file
  6. 進入coding檢視release分支的程式碼是否有被更新，程式碼已更新則繼續下面步驟，沒有被更新則查詢原因
  7. 執行發版指令碼
  8. 通知對應的開發人員以及測試人員進行生產驗證
  9. 進入coding打上標籤，標籤命名為日期加上a-z的小寫字母

其他

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

相關文章