GitLab Flow 的 11 條規則

Git FLOW 腳本語言 Cherry 零空科技 2017-05-20

使用 Git 進行版本管理,是對 Git 之前所有方法的改進。然而,很多組織最終會出現凌亂的工作流程,或過於複雜的工作流程。這問題對於從另一版本控制系統轉換過來的組織來說尤為突出。

本文中,我們為 GitLab 工作流程制定了11條規則,以幫助簡化和清晰。規則的主要好處(或者說我們希望的好處)是它簡化過程,併產生更加有效和更清晰的結果。

總是存在改善空間,一切均為草稿。一如既往,人人皆可貢獻!非常歡迎提出反饋意見!

1. 使用功能分支,不直接提交(commit)到 master分支。

如果你從 SVN 轉過來,舉例來說,你會習慣於基於主幹(trunk)的工作流程。而使用 Git 時,任何正在進行的操作,都應為之創建一個分支(branch),以便最終在合併(merge)之前進行代碼審查(code review)。

2. 測試所有的提交,而不僅僅只在 master分支上。

有些人將 CI 系統設置為只測試合併到 master分支的東西。這太遲了!總是擁有綠色的 master測試(譯者注:綠色在 CI 裡通常意味著測試通過,而紅色意味著測試失敗),人們會覺得有信心。例如,在開始開發新功能之前,人們不得不測試 master分支那是沒有意義和荒謬的。CI 並不昂貴,所以這樣做是最好的。

3. 在所有的提交上,運行所有的測試(如果你的測試時間長於 5 分鐘則讓它們並行)。

如果您正工作在一個功能分支並添加新提交(commit),請隨之運行測試。如果測試需要很長時間,請嘗試並行運行。合併請求(merge requests)時,在服務器端來執行此操作以運行完整的測試套件。如果你有一個用於開發的測試套件,而另一個測試套件你只為新版本運行;那麼設置並行測試並運行全部測試套件是值得的。

4. 在合併到 master 之前執行代碼審查,而不是事後審查。

不要在一週結束時測試一切。當場就搞!這樣你更有可能抓住可能導致問題的東西,而其他人也會努力提出解決方案。

5. 部署是自動的,並基於分支或標籤(tag)。

如果您不想每次都部署 master分支,那麼你可以創建一個 production 分支;但你沒理由用腳本(script)或登錄到某個地方手動操作。自動化一切,或以特定分支來觸發生產部署。

6. 標籤(tag)是由用戶設置的,而不是由 CI 創建。

應由用戶來打標籤(tag),並且基於此,CI 將執行一個動作。不應讓 CI 去更改代碼庫。如果你需要非常詳細的指標,你應該有一個服務器報告來詳細說明新版本。

7. 發佈(release)是基於標籤(tag)的。

如果你打了 tag,則意味著創建了一個新版本。

8. 永遠不對已推送的提交(pushed commits)進行變基(rebase)。

當你推送(push)到公共分支後,你就不該對其變基,因為這樣會很難跟進你正在改進的內容,很難跟進測試結果是什麼,而且它打破了 cherry-picking。有時我們在審查流程的後期要求代碼貢獻者合併及變基(git merge --squash),以使一些東西容易還原時,我們也會違背這一規則。但一般而言,準則是:代碼應乾淨,修改歷史應真實。

9. 每個人都從 master分支開始工作,目標也是 master分支。

這意味著沒有任何長期分支。你可以檢出 master分支,構建功能,創建合併請求,並再次指向到 master分支。在合併之前,應該進行完整的代碼審查,而不應在代碼審查和合並間存在任何中間階段。

10. 在 master分支中修正錯誤,其次再到發佈分支。

如果你發現 bug,最糟的事莫過於你在剛發佈的版本里修復了它,而未在 master
分支修復。為避免這種情況,應總是向前修復(fix forward)。在 master中修復,然後 cherry-pick 到其他補丁發佈分支。

11. 提交信息(commit message)應體現意圖。

不僅要說明你做了什麼,還應說明為什麼這麼做。如果解釋一下為什麼這麼做,而不是用其他方式,這會更加有用。

更多內容請移步 GitLab Flow 文檔。

相關推薦

推薦中...