Git Workflow 工作指南

isZoe發表於2018-01-12
Git

分支策略

  • 程式碼庫的常設分支始終只有 master 和 develop，臨時分支最後都刪除。
  • 臨時分支合併到常用分支時，必須發起 Pull / Merge Requset ，並指定一個人 code review。
  • 遠端臨時分支由發起者追蹤和維護， reviewer 負責刪除。
  • 所有的開發和迭代儘量都在臨時分支上。
  • 開發記錄、功能整合、測試歷史由 develop 分支管理，正式釋出記錄由 master 分支管理。
  • 釋出和部署時，必須新建釋出分支。（釋出分支基於 develop 分支）
  • 釋出和部署完成後，必須將釋出分支合併回 develop / master 分支，然後刪除釋出分支。
  • 合併到 master 分支的程式碼必須打上 Tag。（Tag：版本號、描述、日期）

常用分支

  • master
  • develop

master: 正式釋出

master 分支上存放的應該是隨時可供在生產環境中部署的程式碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的程式碼時，master 分支上的程式碼會被更新。同時，每一次更新，需要新增對應的版本號標籤（TAG）。

develop: 日常開發

develop 分支是儲存當前最新開發成果的分支。通常這個分支上的程式碼也是可進行每日夜間釋出的程式碼（Nightly build）。因此這個分支有時也可以被稱作“integration branch”。

臨時分支

  • 功能分支（feature）
  • 釋出分支（release）
  • 修補分支（hotfix）

功能分支

功能分支，開發新功能都從 develop 分支出來，從 develop 分支上面分出來的。開發完成後，要再併入 develop。

# 建立一個功能分支：
git checkout -b feature-x develop

# 開發完成後，將功能分支合併到develop分支：
git checkout develop
git merge --no-ff feature-x

# 刪除feature 分支：
git branch -d feature-x
釋出分支

釋出分支，準備要 release 的版本，只修 bugs。從 develop 分支上面分出來，釋出結束以後，必須合併進 develop 和 master 分支。

# 建立一個釋出分支：
git checkout -b release-1.2 develop

# 確認沒有問題後，合併到master分支：
git checkout master
git merge --no-ff release-1.2

# 對合並生成的新節點，做一個標籤
git tag -a 1.2

# 再合併到develop分支：
git checkout develop
git merge --no-ff release-1.2

# 最後，刪除釋出分支：
git branch -d release-1.2

修補分支

修補分支，是指等不及 release 版本就必須馬上修 master 趕上線的情況。它是從 master 分支上面分出來的。修補結束以後， 再合併進 master 和 develop 分支。

# 建立一個修補bug分支：
git checkout -b hotfix-0.1 master

# 修補結束後，合併到master分支：
git checkout master
git merge --no-ff hotfix-0.1
git tag -a 0.1.1

# 再合併到develop分支：
git checkout develop
git merge --no-ff hotfix-0.1

# 最後，刪除"修補bug分支"：
git branch -d hotfix-0.1

Pull / Merge Request

程式碼合併到 master/develop 分支：

  1. 將需要合併到 master / develop 的分支 push 到 gitlab。
  2. 進入工程 -> merge request -> create new merge request 。
  3. 選擇源分支、目標分支，確定。
  4. review 負責人進入 merge request，確認沒有問題之後選擇 Auto Merge（或者手動在本地合併之後再 push 到 gitlab），並關閉這個 merge request，完成。
  5. 如果發現問題那麼在有問題的行下注釋，並提醒 request 的發起人及時修改。
  6. 刪除本地臨時分支，本地 master / develop 更新到最新狀態。

Code Review

  • 提交 Pull / Merge Request 時， Commit 和 Message 要足夠清晰詳細。 切記，如果一次提交的內容包含很多 Commit，請不要使用自動生成的描述。 請用簡短且足夠說明問題的語言（理想是控制在3句話之內）來描述：

你改動了什麼，解決了什麼問題，需要程式碼審查的人留意那些影響比較大的改動。特別需要留意，如果對基礎、公共的元件進行了改動，一定要另起一行特別說明。

  • 稽核人員邀請原則：專案參與人員 & 團隊同事 & 團隊 Leader。（對專案足夠了解，對專案足夠了解，對專案足夠了解，重要的事情說三遍）；
  • 評論中至少出現一個 lgtm 且保證程式碼評審通過之後 Pull / Merge Request 才可以被合併；（注：lgtm 即 looks good to me 的縮寫）

Git Command

git tag

# 建立一個帶版本有描述的 tag
git tag -a v0.1.0 -m `commit`
# 覆蓋該版本已有 v0.1.0 
git tag -f v0.1.0 
# 推送伺服器
git push origin --tags
# 伺服器已有 v0.1.0，強制推到伺服器
git push origin -f v0.1.0 
# 伺服器獲取剛剛的 v0.1.0
git fetch --tag
# 刪除本地版本
git tag -d v0.1.0
# 刪除伺服器上的tag
git push origin :v0.1.0
git merge

# 不使用 fast-forward 方式合併，保留分支的 commit 歷史
git merge --no-ff develop
# 使用 squash 方式合併，把多次分支commit歷史壓縮為一次
git merge --squash develop
git checkout

# 放棄在 file.txt 的修改，恢復成未修改時的樣子
git checkout file.txt
# 當前目錄所有修改的檔案，恢復成未修改時的樣子
git checkout .
# 建立新的分支，並切換過去
git checkout -b branchname
git reset

# 回退指定的 commit 
git reset 0c5602affd27d2224d151284bd1c6e033fd9023f
# 回退上次修改
git reset --hard
git flow

# git flow 初始化
git flow init
# 建立一個新的 feature 分支
git flow feature start name
# 將 feature 分支推送到遠端倉庫
git flow feature publish name
# 當特性開發完畢，需要將此分支合併到 develop 分支
git flow feature finish name

參考

Git分支管理策略
GitLab Flow的使用
Git檢視、刪除、重新命名遠端分支和tag
Git工作流指南：Gitflow工作流
Git 在團隊中的最佳實踐–如何正確使用Git Flow

相關文章