使用 Git 版本控制，是對使用它之前的所有版本控制方式的一種改進。然而，很多組織最終以太過混亂或過於復雜的流程來結束。這個問題對於剛從其他版本控制系統轉過來的組織來說特別突出。
在本文中我們會列出 GitLab 工作流 的11條規則，以幫助簡化、整理工作流程。這些規則最主要的益處是(或我們希望是) 它能夠簡化流程並且產生一個更高效和更清楚的成果。
我們認為總會有可改善的空間，並且每一次改善都是草案。一如既往，每個人都可以做出貢獻!反饋和提意見是非常受歡迎的。
如果你從 SVN過來，例如，你將習慣於基於trunk的工作流。當使用Git的時候，你應該為你做的任何事情創建一個分支，以便你以merge前的代碼評審作為結束。
一些人設置他們的CI僅僅測試那些被合並到master的提交。這太遲了;對於master總是綠色的測試人們應感到有信心。對人們來說在他們開始開發新功能前不得不測試master是沒有意義的，例如，CI不是很昂貴，所以按這種方式做才有意義。
如果你工作在一個特性分支並添加新提交,然后在那個分支運行測試。如果測試花費較長時間，試着並行的運行它們。在服務端的合並請求運行所有的測試套件。如果你有一個服務於開發的測試套件，另一個僅僅是對新版本的，那么值得設置並行測試，分別運行它們。
不要在一周結束的時候測試所有的東西。 當場做,因為你會更容易抓住可能導致問題的事情，其他人也會努力想出解決方案。
如果你不想每次部署master，可以創建一個生產分支。但是這里沒有理由為什么你可能使用一個腳本或登錄到某個地方手動部署。讓一切自動化，或者一個特定的分支觸發一次生產部署。
用戶創建一個基線，基於那個基線，CI將執行一個操作。你不應該讓CI更改代碼倉庫。如果你需要非常詳細的指標，您應該有一個服務器報告列出了新版本。
如果你為你的項目生成tag，這表示你發布了一個新版本。
如果你將一個項目的變更提交到一個公共的分支上，你不應該使用重置方式(即不應用 git rebase),否則將造成難以追蹤你對該項目的改善和相應的測試結果，這樣做實際上破壞了他人選擇最有利於的版本的依據。
我們有時也違反這條准則，當我們要求一個貢獻者使用(git merage --spansh)提交他的修改，以便提供真實的修改歷史，忽略他本地不規范的修改歷史時。這樣做以后查閱修改歷史時，容易根據修改歷史做版本恢復。但是總而言之 推薦做法為：代碼應該純凈，修改歷史應該真實。
這意味着你不從任何分支開始。你檢出主支內容,然后創建你的特性，提交你的合並請求，下次修改還是以主支為基礎。在你合並內容到主枝上時，你應該完成審查，不應該包含其他中間階段的內容。
如果你發現一個bug，最差的事是你修改了剛發布的版本，而未修改主支。
避免這種情況發生，你應該總是先修改主枝，之后再發布另外一個版本用來修復已發布版本中的錯誤。
你應該不止說明你做了什么，還應該說明你為什么這么做。如果你解釋為什么這么做而沒有使用其他方式，這將會更有用。
本文轉載地址：https://www.linuxprobe.com/eleven-rule-gitlab.html