工作中如何打造優雅的 Git 工作流和 Commit 規範！

前言

🤓Git 大家都非常熟悉了，就不做過多介紹，但是如何用好 Git、如何進行合理的分支開發、Merge 你是否有一個規範流程呢？💤

不論是一個團隊一起開發一個項目，還是自己獨立開發一個項目，都少不了要和 Git 打交道，這些都是作爲開發者必須要掌握的。每個團隊也許有自己的 Git 工作流，今天小許給你分享一個通用的流程和規範。

既然說到 Git 得先有個協同原則📜:

統一使用 Git 作爲版本控制的主要工具。

統一使用 GitFlow 流程管理控制版本

基本命令操作

我們來看下 git 的基本操作，這些命令基本可以完成我們日常對代碼版本開發合併需求，同時小許在文末給老闆們準備了一份【Git 命令大全】，值得你收藏！

git add . ：將變更從工作目錄移至暫存區域

git commit -m "fix: xxx" ：將暫存區中的文件提交到本地倉庫中分支中

git pull：用於從遠程獲取代碼併合並本地的版本

git push：用於從將本地的分支版本上傳到遠程併合並

這些操作命令在各個工作區、倉庫之間如何進行流轉的呢？如下圖

git 有好幾個區，工作區（workspace）、暫存區（indexStage）、本地倉庫（local repository）、還有遠程倉庫（remote repository）。

遠程倉庫爲我們保存一份代碼，如 github，而工作區、暫存區和本地倉庫都在本地

常用分支建議

前面簡單講了下代碼提交流程，但是版本控制並不是簡單代碼提交就完事了，這裏分享一些常用的分支開發，但並不是任何項目都一定按照這種分支結構來定義，按你的需求來確定需要哪些。比如你一個人開發一個小型項目，那麼就不用搞的那麼複雜，如果是多人協同開發版本迭代較快，那麼下面的分支內容會讓你開發節奏更清晰合理！

生產分支（master）‌

master 分支是倉庫的主分支，也有人叫 production 分支，這個分支包含最近發佈到生產環境的代碼，最近發佈的 release，這個分支只能從其他分支合併，不能在這個分支直接修改‌

master 分支一般由 release、develop 以及 hotfix 分支合併，任何時間都不能直接修改代碼

開發分支（develop）‌

這個分支是我們的主開發分支，始終保持最新完成以及 bug 修復後的代碼.

包含所有要發佈到下一個 release 的代碼，這個主要合併與其他分支，比如 feature 分支‌

一般開發的新功能時，feature 分支都是基於 develop 分支下創建的

補丁分支（hotfix）‌

當我們在生產環境發現新的 Bug 時候，我們需要基於 master 分支創建一個 hotfix 分支，然後在 hotfix 分支上修復 bug

完成 hotfix 後，我們要把 hotfix 分支合併回 master 和 develop 分支‌，所以 hotfix 的改動會進入下一個 release

發佈分支（release)‌

當你需要發佈一個新功能的時候，要基於 develop 分支創建一個 release 分支

在 release 分支做爲基準進行測試並修復 bug，完成 release 後，把 release 合併到 master 和 develop 分支‌

release 分支爲預上線分支，發佈提測階段，會 release 分支代碼爲基準提測

功能分支（feature）‌

feature 分支主要是用來開發一個新的功能，一旦開發完成，我們合併回 develop 分支，然後提交合並請求到 release 分支進行提測。

分支命名: feature/ 開頭的爲特性分支，命名規則: feature/user_module、 feature/cart_module

Git 工作流

上面那麼多種分支類型，而且不同的分支又是基於其他分支，每次看完之後都記得，但是結合起來發現僅僅停留在有印象，是的，我們不好從單純的文字上理清分支之間的關係和合並方式。

沒關係，小許用個圖把之間的關係梳理清楚：

其實核心是要弄明白主幹和各個開發分支的關係，以及你的開發分支該和誰去合併。

不過還是那句話根據自己的項目和業務團隊去指定 Git 工作，不能爲了更風去創建並不適合團隊的分支，不然會導致開發在無聊的敲命令，花費時間在各種分支的合併上，反而降低了效率。

適合別人的未必適合大家，互相交流，選擇合適自己的！

更多方位的流程，大家可以看看這篇文章# 字節研發設施下的 Git 工作流

Commit 編寫規範

好的 Commit messages 日誌編寫會帶來極大的幫助，它也反映了一個開發人員是否是良好的協作者，更重要的是在後續修復 bug 和實現新的 feture 時，對於之前實現的功能、解決的 bug 可以一目瞭然，而不用通過閱讀代碼去了解曾經的實現，因爲這會是意見非常痛苦的事情！

忘了說，你的 Commit messages 會是 Code Review 人員參考基本，你應該不想被無情的打回吧？😅😅😅

目前，社區有多種 Commit messages 的寫法規範。來自 Angular （前端框架）規範是目前使用最廣的寫法，比較合理和系統化。

其實瀏覽過 Github 開源項目的同學，如果有注意 Pull requests 的話就有了解，行我們看下 Angular 的提交規範到底是咋樣的，爲啥會成爲參考標杆🚩🚩🚩。

Commit messages 提交可以參照以下格式

<type>: <subject>
<BLANK LINE> 空白行
<body>
<BLANK LINE> 空白行
<footer>

• type: 本次 commit 的類型，諸如 bugfix docs style 等
• scope: 本次 commit 波及的範圍
• subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特意強調了幾點： . 使用祈使句，是不是很熟悉又陌生的一個詞，來傳送門在此祈使句 . 首字母不要大寫 . 結尾無需添加標點
• body: 同樣使用祈使句，在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |
• footer: 描述下與之關聯的 issue 或 break change

Commit Type 的類別

• feat: 添加新特性
• fix: 修復 bug
• docs: 僅僅修改了文檔
• style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
• refactor: 代碼重構，沒有加新功能或者修復 bug
• perf: 增加代碼進行性能測試
• test: 增加測試用例
• chore: 改變構建流程、或者增加依賴庫、工具等

Commit messages 格式要求

標題行：50 個字符以內，描述主要變更內容

主體內容：更詳細的說明文本，建議 72 個字符以內。需要描述的信息包括:

• 爲什麼這個變更是必須的? 它可能是用來修復一個 bug，增加一個 feature，提升性能、可靠性、穩定性等等
• 他如何解決這個問題? 具體描述解決問題的步驟
• 是否存在副作用、風險?

如果需要的化可以添加一個鏈接到 issue 地址或者其它文檔

來看這個這位老哥在 Angular 項目詳細的 commit 信息，大家可以對照上面的規範看，可以用一個詞描述這種好的 Commit 方式【“賞心悅目”】，也許這也就是爲什麼這個項目的 Commit 會成爲衆多人模仿的原因吧！

關於名詞簡稱

軟件團隊中經常需要 Git 進行團隊協作開發，但是不少職場小寶朋友對於從大佬口中冒出來的一些字母縮略詞一臉矇蔽，比如 MR、CR，這裏一次說個明白，讓你不再迷茫各種簡稱，哈哈！

這裏總結了一些，

• CR：Code Review. 請求代碼審查。
• PR： pull request. 拉取請求，給其他項目提交代碼。
• MR： merge request. 合併請求
• ACK：Acknowledgement. 承認，同意。表示接受代碼的改動。
• TL;DR：Too Long; Didn't Read. 太長懶得看。常見於 README 文檔。
• WIP：Work In Progress. 進展中，主要針對改動較多的 PR，可以先提交部分，標題或 Tag 加上 WIP，表示尚未完成，這樣別人可以先 review 已提交的部分。
• RFC：Request For Comment. 請求進行討論，表示認爲某個想法很好，邀請大家一起討論一下

最全 Git 命令

在文章末尾，分享一下收藏的一個非常全面的 Git 命令總結，分享給大家！工作日愉快各位

參考：字節研發設施下的 Git 工作流

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/LXiqJeYYK6DjLg2LMIp1-Q

前言