使用 Git 版本控制，是對使用它之前的所有版本控制方式的一種改進。然而，很多組織最終以太過混亂或過于復雜的流程來結束。這個問題對于剛從其他版本控制系統(tǒng)轉過來的組織來說特別突出。

在本文中我們會列出 GitLab 工作流 的11條規(guī)則，以幫助簡化、整理工作流程。這些規(guī)則最主要的益處是(或我們希望是) 它能夠簡化流程并且產生一個更高效和更清楚的成果。

我們認為總會有可改善的空間，并且每一次改善都是草案。一如既往，每個人都可以做出貢獻!反饋和提意見是非常受歡迎的。

1. 使用功能分支，不直接提交到master。

如果你從 SVN過來，例如，你將習慣于基于trunk的工作流。當使用Git的時候，你應該為你做的任何事情創(chuàng)建一個分支，以便你以merge前的代碼評審作為結束。

2. 測試所有的提交，不僅僅是master上的提交。

一些人設置他們的CI僅僅測試那些被合并到master的提交。這太遲了;對于master總是綠色的測試人們應感到有信心。對人們來說在他們開始開發(fā)新功能前不得不測試master是沒有意義的，例如，CI不是很昂貴，所以按這種方式做才有意義。

3. 在所有的提交上運行所有的測試(如果運行測試多于5分鐘，并行運行它們)。

如果你工作在一個特性分支并添加新提交,然后在那個分支運行測試。如果測試花費較長時間，試著并行的運行它們。在服務端的合并請求運行所有的測試套件。如果你有一個服務于開發(fā)的測試套件，另一個僅僅是對新版本的，那么值得設置并行測試，分別運行它們。

4. 在合并到master前執(zhí)行代碼評審，而非事后。

不要在一周結束的時候測試所有的東西。 當場做,因為你會更容易抓住可能導致問題的事情，其他人也會努力想出解決方案。

5. 部署是自動的，基于分支或基線。

如果你不想每次部署master，可以創(chuàng)建一個生產分支。但是這里沒有理由為什么你可能使用一個腳本或登錄到某個地方手動部署。讓一切自動化，或者一個特定的分支觸發(fā)一次生產部署。

6. 基線是人為創(chuàng)建，而不是CI創(chuàng)建。

用戶創(chuàng)建一個基線，基于那個基線，CI將執(zhí)行一個操作。你不應該讓CI更改代碼倉庫。如果你需要非常詳細的指標，您應該有一個服務器報告列出了新版本。

7. 依賴tags版本進行發(fā)布

如果你為你的項目生成tag，這表示你發(fā)布了一個新版本。

8.絕不以重置方式提交變更

如果你將一個項目的變更提交到一個公共的分支上，你不應該使用重置方式(即不應用 git rebase),

否則將造成難以追蹤你對該項目的改善和相應的測試結果，這樣做實際上破壞了他人選擇最有利于的版本的依據。

我們有時也違反這條準則，當我們要求一個貢獻者使用(git merage --spansh)提交他的修改，以便提供真實的修改歷史，忽略他本地不規(guī)范的修改歷史時。這樣做以后查閱修改歷史時，容易根據修改歷史做版本恢復。但是總而言之 推薦做法為：代碼應該純凈，修改歷史應該真實。

9. 每個人都應該從主支開始，并一直以主支為基礎。

這意味著你不從任何分支開始。你檢出主支內容,然后創(chuàng)建你的特性，提交你的合并請求，下次修改還是以主支為基礎。在你合并內容到主枝上時，你應該完成審查，不應該包含其他中間階段的內容。

10. 先修改主支中的錯誤，之后發(fā)布分支。

如果你發(fā)現一個bug，最差的事是你修改了剛發(fā)布的版本，而未修改主支。

避免這種情況發(fā)生，你應該總是先修改主枝，之后再發(fā)布另外一個版本用來修復已發(fā)布版本中的錯誤。

11. 提交的信息中反應你修改部分的意圖

你應該不止說明你做了什么，還應該說明你為什么這么做。如果你解釋為什么這么做而沒有使用其他方式，這將會更有用。