Check-in Dance

流程

• (1) Run tests in local

  本地運行測試，保證測試通過，如果有失敗就立即修復(fù)，直至測試成功：$ mvn test

• (2) Check CI status
  檢查 CI 狀態(tài)，確認現(xiàn)在可以拉取代碼

• (3) Pull
  開發(fā)新代碼之前，從 CI 完全成功的那個最新版本檢出代碼：$ git pull --rebase

• (4) Run tests in local
  本地運行測試，保證測試通過，如果有失敗就立即修復(fù)，直至測試成功：$ mvn test

• (5) Make changes
  按照 red -> green -> refactor 方式編寫代碼；

  • red：根據(jù) Task 拆分，添加一個新的測試 （由于目前沒有實現(xiàn)代碼，測試失?。?/li>
  • green：添加最少的實現(xiàn)代碼，使測試通過
  • refactor：識別代碼中的 bad smell，重構(gòu)代碼

• (6) Run tests in local
  完成一個小特性以后，本地運行測試通過，如果有失敗就立即修復(fù)，直至測試成功：$ mvn test

• (7) Review Changes
  在 IntelliJ 下 Alt + 9 review Local Changes

• (8) Commit to local
  本地提交，小步提交，寫清楚 Story 編號有意義的提交信息；

$ git add .
$ git commit -m "[US27149] Add entity validation in creation process"

• (9) Check CI status
  檢查 CI 狀態(tài)，確認現(xiàn)在可以拉取代碼；

• (10) Pull
  從遠端拉取最新代碼：$ git pull --rebase
  如果有沖突，修復(fù)有沖突的文件，然后

$ git add .
$ git rebase --continue

• (11) Run tests in local
  本地運行測試，保證測試通過，如果又失敗就立即修復(fù)，直至測試成功：$ mvn test

• (12) Push
  本地 commit 通過測試之后，盡早 push 到遠端，以便團隊其他人員在新代碼庫上工作：$ git push

• (13) Check CI status
  查看自己 push 之后，CI 狀態(tài)正常

注意事項

• (1) 在步驟10中，頻繁與遠端代碼庫合并，避免 big bang conflict。如果本地已經(jīng)較長時間沒有拉取代碼庫的代碼，并且觀察到其他成員已經(jīng)進行了較多 commit，而本地有未完成工作不能 commit，如何同步遠端代碼庫的代碼呢？

我們可以先暫存目前的工作，拉取遠端的最新代碼，然后取回目前的工作與遠端代碼進行合并。這樣可以將合并前移，盡量避免 big bang conflict。

$ git stash
$ git pull --rebase
$ git stash pop

• (2) 本地測試通過之后，盡早 push，避免big bang conflict

Git 簡介

基礎(chǔ)知識

Git 有三種狀態(tài)，你的文件可能處于其中之一：已提交（committed）、已修改（modified）和已暫存（staged）。 已提交表示數(shù)據(jù)已經(jīng)安全的保存在本地數(shù)據(jù)庫中。 已修改表示修改了文件，但還沒保存到數(shù)據(jù)庫中。 已暫存表示對一個已修改文件的當(dāng)前版本做了標(biāo)記，使之包含在下次提交的快照中。

由此引入 Git 項目的三個工作區(qū)域的概念：Git 倉庫、工作目錄以及暫存區(qū)域。

git-area.png

常用命令

$ git status                      # 查看文件處于什么狀態(tài)
$ git log                         # 查看提交歷史
$ git add <filename>              # 將需要提交的文件從 Working Directory 添加到 Staging Area
$ git commit -m <message>         # 將 Staging Area 中的文件快照永久性移動到 Repository
$ git commit --amend              # 修改上次提交
$ git pull --rebase               # 拉取遠端代碼，將本地修改衍合到本地最新代碼上
$ git push                        # 將本地提交推送到遠端倉庫
$ git merge <branchname>          # 合并分支
$ git checkout -b <branchname>    # 新建并切換 Working Directory 到新分支
$ git checkout -- <filename>      # 丟棄文件修改，還原文件狀態(tài)到上次提交的狀態(tài)
$ git revert HEAD~<number>        # 找到倒數(shù)第<number>個提交，并創(chuàng)建一個新的提交來撤銷之后的更改
$ git reset HEAD^ <filename>      # 將當(dāng)前的某個 file 從緩存區(qū)移出，不影響工作目錄對其進行的修改
$ git reset --hard HEAD~<number>  # 移除最后<number>個提交，并將緩存區(qū)和工作目錄同步到指定的提交 

代碼回滾

Revert

Revert 撤銷一個提交的同時會創(chuàng)建一個新的提交。這是一個安全的方法，因為它不會重寫提交歷史。比如，下面的命令會找出倒數(shù)第二個提交，然后創(chuàng)建一個新的提交來撤銷這些更改，然后把這個提交加入項目中。

$ git checkout hotfix
$ git revert HEAD~2

reverting.png

在提交層面上，reset 將一個分支的末端指向另一個提交。這可以用來移除當(dāng)前分支的一些提交。比如，下面這兩條命令讓 hotfix 分支向后回退了兩個提交。

$ git checkout hotfix
$ git reset HEAD~2

hotfix 分支末端的兩個提交現(xiàn)在變成了懸掛提交。也就是說，下次 Git 執(zhí)行垃圾回收的時候，這兩個提交會被刪除。換句話說，如果你想扔掉這兩個提交，你可以這么做。reset 操作如下圖所示：

resetting.png

如果你的更改還沒有共享給別人，git reset 是撤銷這些更改的簡單方法。當(dāng)你開發(fā)一個功能的時候發(fā)現(xiàn)「糟糕，我做了什么？我應(yīng)該重新來過！」時，reset 就像是 go-to 命令一樣。

除了在當(dāng)前分支上操作，你還可以通過傳入這些標(biāo)記來修改你的緩存區(qū)或工作目錄：

--soft – 緩存區(qū)和工作目錄都不會被改變
--mixed – 默認選項。緩存區(qū)和你指定的提交同步，但工作目錄不受影響
--hard – 緩存區(qū)和工作目錄都同步到你指定的提交

把這些標(biāo)記想成定義 git reset 操作的作用域就容易理解多了。

scope-of-reset.png

當(dāng)你傳入 HEAD 以外的其他提交的時候要格外小心，因為 reset 操作會重寫當(dāng)前分支的歷史。正如 rebase 黃金法則所說的，在公共分支上這樣做可能會引起嚴重的后果。下表總結(jié)了 reset、checkout 和 revert 應(yīng)用到文件層面和提交層面的常用場景。

CI 變紅之后的操作指導(dǎo)

責(zé)任人

• (1) 提交之后 Working Directory 或 Stage Area 是否存在未 commit 的修改

  • 如果存在未 commit 的修改

$ git stash  # 保存目前的修改，工作區(qū)和暫存區(qū)內(nèi)容回到問題提交點的狀態(tài) 
$ git status # 確認狀態(tài)是否正確 

• (2) 運行測試

  • 測試未通過，說明 push 之前沒有在本地運行測試，未按照 check-in dance 的步驟提交代碼

    可以自己打臉提醒一下，不要再犯，暫時放下其他工作，開始全力 Debug 吧

  • 測試通過，說明很有可能是因為本地環(huán)境與 CI 環(huán)境不同，比如數(shù)據(jù)不一致等原因

    可以自己打臉清醒一下，暫時放下其他工作，開始全力 Debug 吧

• (3) bug 修復(fù)流程

$ git checkout -b hot-fix   # 創(chuàng)建并切換到 hot-fix 分支，在該分支修復(fù) bug

• (4) 15分鐘之內(nèi)，是否完成了 bug 修復(fù)

完成了 bug 修復(fù)，并在本地經(jīng)過了測試驗證

$ git add .                   # 將修改保存到暫存區(qū)，準備提交
$ git commit -m <message>     # 將修改提交到 hot-fix 分支
$ git checkout master         # 切換到 master 分支
$ git rebase master hot-fix   # 將 bug 修改過程在 master 分支重演
$ git pull --rebase           # 原則上 CI 紅了其他人不能提交，這一步可以忽略
$ git push                    # 將修改提交到遠端

未完成 bug 修復(fù)

$ git stash                   # 保存在 hot-fix 分支未完成的修復(fù)工作
$ git checkout master         # 切換到 master 分支
$ git revert <commit hash>    # 創(chuàng)建一個 revert 提交撤銷引入 bug 的修改
$ git pull --rebase           # 原則上 CI 紅了其他人不能提交，這一步可以忽略
$ git push                    # 回退 CI 的代碼，先修復(fù) CI，保證其他人可以提交
$ git checkout hot-fix        # 切換回 hot-fix 分支
$ git stash pop               # 恢復(fù)目前已經(jīng)進行的修復(fù)工作，繼續(xù)修復(fù)
$ git add .                   # 修復(fù)完成，將修改保存到暫存區(qū)，準備提交
$ git commit -m <message>     # 將修改提交到 hot-fix 分支
$ git checkout master         # 切換到 master 分支
$ git rebase master hot-fix   # 將 bug 修改過程在 master 分支重演
$ git pull --rebase           # 原則上 CI 紅了其他人不能提交，這一步可以忽略
$ git push                    # 將修改提交到遠端    

其他成員

1. CI 變紅之后暫停提交代碼，直至 CI 變綠

2. CI 變綠之后

$ git stash                        # 保存目前的工作，如果工作區(qū)和暫存區(qū)是干凈的，忽略此步驟
$ git pull --rebase                # 拉取最新的修復(fù)之后的代碼
$ git stash pop                    # 恢復(fù)當(dāng)前工作區(qū)，繼續(xù)工作

參考文獻

1. 代碼回滾：Reset、Checkout、Revert-的選擇
2. Git Branch and Merging