祖師爺 Linus 在創(chuàng)造了偉大的 Linux 之后，又創(chuàng)造了應(yīng)用最廣泛的代碼管理工具 —— Git，極大地提高了程序員的生產(chǎn)力。 現(xiàn)如今大部分項(xiàng)目都在使用 Git 作為代碼管理工具，不論是在代碼管理、版本控制以及團(tuán)隊(duì)協(xié)作上，Git 相比其他版本控制軟件都有著無可比擬的優(yōu)勢。

雖然 Git 是個優(yōu)秀的工具，但是在項(xiàng)目中是否能夠正確合理地使用，是否能夠發(fā)揮其最大的優(yōu)勢，就我自己這幾年的工作經(jīng)歷來看，對于大部分團(tuán)隊(duì)這個問題的答案是否定的。

大部分程序員對 Git 的使用基本上都停留在 git add、git commit、git push、git pull 這幾個指令上，而且大部分團(tuán)隊(duì)也沒有 Git 規(guī)范，提交信息充斥著大量的 “fix”、“update”，分支管理也很混亂，代碼提交哪個分支上也沒具體的規(guī)定，導(dǎo)致在團(tuán)隊(duì)協(xié)作過程中經(jīng)常出現(xiàn)代碼合并后誰的代碼不見了，修過的 bug 在新版本又出現(xiàn)了……

0. 我們可能面臨的問題

試想遇到以下這些問題，你會采取怎樣的方式去解決：

• 需要線上某個歷史版本的源碼，直接在 develop 分支根據(jù)提交記錄和時間找對應(yīng)的節(jié)點(diǎn)？
• 線上版本出現(xiàn)嚴(yán)重 bug 需要緊急修復(fù)發(fā)版本，而你的項(xiàng)目就一個分支，上個版本發(fā)布之后已經(jīng)有大量改動了，怎么辦？
• 某個提交改動了部分代碼，涉及到 10 幾個文件，現(xiàn)在這個改動不需要了，此時要一個個找出這些文件然后再改回去么？
• 出現(xiàn)了一個 bug，之前好像處理過，但是現(xiàn)在忘了當(dāng)初怎么處理的了，在一堆寫著 “fix bug”、“update” 的提交記錄中，如何找到當(dāng)初那筆的提交？
• 某個功能本來準(zhǔn)備發(fā)布的，現(xiàn)在突然決定這個版本不上了，現(xiàn)在要一處處找到之前的代碼，然后再改回去？
• ……

以上這些問題在我們的項(xiàng)目中都是會或多或少出現(xiàn)的，部分問題可能涉及到的是對 Git 的功能是否熟悉的問題，大部分問題則是涉及到一個項(xiàng)目的 Git 使用規(guī)范問題，如果有一個很好的規(guī)范，在項(xiàng)目中合理地使用 Git，很多問題壓根就不是問題。

1. Git 規(guī)范的必要性

既然認(rèn)同需要一份 Git 規(guī)范，那么這個規(guī)范需要規(guī)范哪些內(nèi)容，解決哪些問題，又帶來哪些好處呢？個人認(rèn)為有以下幾點(diǎn)：

1. 分支管理

• 代碼提交在應(yīng)該提交的分支
• 隨時可以切換到線上穩(wěn)定版本代碼
• 多個版本的開發(fā)工作同時進(jìn)行

2. 提交記錄的可讀性

• 準(zhǔn)確的提交描述，具備可檢索性
• 合理的提交范圍，避免一個功能就一筆提交
• 分支間的合并保有提交歷史，且合并后結(jié)果清晰明了
• 避免出現(xiàn)過多的分叉

3. 團(tuán)隊(duì)協(xié)作

• 明確每個分支的功用，做到對應(yīng)的分支執(zhí)行對應(yīng)的操作
• 合理的提交，每次提交有明確的改動范圍和規(guī)范的提交信息
• 使用 Git 管理版本迭代、緊急線上 bug fix、功能開發(fā)等任務(wù)

以上就是一份 Git 規(guī)范的作用和使命。

接下來結(jié)合 Git-Flow 和個人實(shí)際的項(xiàng)目經(jīng)驗(yàn)，總結(jié)了一份項(xiàng)目中使用 Git 的規(guī)范，其中大部分內(nèi)容都是對 Git-Flow 進(jìn)行一個解讀和擴(kuò)展，告訴大家為什么這么做以及怎么做。

以下就是 Git-Flow 的經(jīng)典流程圖：

如果你熟悉 Git-Flow，那么你對上圖中的各種分支和線應(yīng)該都能夠理解，如果你之前沒了解過相關(guān)的知識，那你可能會有點(diǎn)懵，不過在讀完本文之后再看這張圖，應(yīng)該就能夠理解了。

2. 分支管理規(guī)范

2.1 分支說明和操作

• master 分支
• 主分支，永遠(yuǎn)處于穩(wěn)定狀態(tài)，對應(yīng)當(dāng)前線上版本
• 以 tag 標(biāo)記一個版本，因此在 master 分支上看到的每一個 tag 都應(yīng)該對應(yīng)一個線上版本
• 不允許在該分支直接提交代碼
• develop 分支
• 開發(fā)分支，包含了項(xiàng)目最新的功能和代碼，所有開發(fā)都依賴 develop 分支進(jìn)行

• 小的改動可以直接在 develop 分支進(jìn)行，改動較多時切出新的 feature 分支進(jìn)行
• 注： 更好的做法是 develop 分支作為開發(fā)的主分支，也不允許直接提交代碼。小改動也應(yīng)該以 feature 分支提 merge request 合并，目的是保證每個改動都經(jīng)過了強(qiáng)制代碼 review，降低代碼風(fēng)險(xiǎn)
• feature 分支
• 功能分支，開發(fā)新功能的分支
• 開發(fā)新的功能或者改動較大的調(diào)整，從 develop 分支切換出 feature 分支，分支名稱為 feature/xxx
• 開發(fā)完成后合并回 develop 分支并且刪除該 feature/xxx 分支
• release 分支
• 發(fā)布分支，新功能合并到 develop 分支，準(zhǔn)備發(fā)布新版本時使用的分支
• 當(dāng) develop 分支完成功能合并和部分 bug fix，準(zhǔn)備發(fā)布新版本時，切出一個 release 分支，來做發(fā)布前的準(zhǔn)備，分支名約定為release/xxx
• 發(fā)布之前發(fā)現(xiàn)的 bug 就直接在這個分支上修復(fù)，確定準(zhǔn)備發(fā)版本就合并到 master 分支，完成發(fā)布，同時合并到 develop 分支
• hotfix 分支
• 緊急修復(fù)線上 bug 分支
• 當(dāng)線上版本出現(xiàn) bug 時，從 master 分支切出一個 hotfix/xxx 分支，完成 bug 修復(fù)，然后將 hotfix/xxx 合并到 master 和 develop 分支(如果此時存在 release 分支，則應(yīng)該合并到 release 分支)，合并完成后刪除該 hotfix/xxx 分支

以上就是在項(xiàng)目中應(yīng)該出現(xiàn)的分支以及每個分支功能的說明。 其中穩(wěn)定長期存在的分支只有 master 和 develop 分支，別的分支在完成對應(yīng)的使命之后都會合并到這兩個分支然后被刪除。簡單總結(jié)如下：

• master 分支: 線上穩(wěn)定版本分支
• develop 分支: 開發(fā)分支，衍生出 feature 分支和 release 分支
• release 分支: 發(fā)布分支，準(zhǔn)備待發(fā)布版本的分支，存在多個，版本發(fā)布之后刪除
• feature 分支: 功能分支，完成特定功能開發(fā)的分支，存在多個，功能合并之后刪除
• hotfix 分支: 緊急熱修復(fù)分支，存在多個，緊急版本發(fā)布之后刪除

2.2 分支間操作注意事項(xiàng)

在團(tuán)隊(duì)開發(fā)過程中，避免不了和其他人一起協(xié)作， 同時也會遇到合并分支等一些操作，這里提交 2 個個人覺得比較好的分支操作規(guī)范。

• 同一分支 git pull 使用 rebase

首先看一張圖：

看到這樣的 提交線圖，想從中看出一條清晰的提交線幾乎是不可能的，充滿了 Merge remote-tracking branch 'origin/xxx' into xxx 這樣的提交記錄，同時也將提交線弄成了交錯縱橫的圖，沒有了可讀性。

這里最大的原因就是因?yàn)槟J(rèn)的 git pull 使用的是 merge 行為，當(dāng)你更新代碼時，如果本地存在未推送到遠(yuǎn)程的提交，就會產(chǎn)生一個這樣的 merge 提交記錄。因此在同一個分支上更新代碼時推薦使用 git pull --rebase。

下面這張圖展示了默認(rèn)的 git pull 和 git pull --rebase 的結(jié)果差異，使用 git pull --rebase 目的是修整提交線圖，使其形成一條直線。

默認(rèn)的 git pull 行為是 merge，可以進(jìn)行如下設(shè)置修改默認(rèn)的 git pull 行為：

# 為某個分支單獨(dú)設(shè)置，這里是設(shè)置 dev 分支git config branch.dev.rebase true# 全局設(shè)置，所有的分支 git pull 均使用 --rebasegit config --global pull.rebase truegit config --global branch.autoSetupRebase always

這里需要說明一下，在我看來使用 git pull --rebase 操作是比較好的，能夠得到一條很清晰的提交直線圖，方便查看提交記錄和 code review，但是由于 rebase 會改變提交歷史，也存在一些不好的影響。這里就不做過多的討論了，有興趣的話可以移步知乎上的討論：在開發(fā)過程中使用 git rebase 還是 git merge，優(yōu)缺點(diǎn)分別是什么？

• 分支合并使用 --no-ff

# 例如當(dāng)前在 develop 分支，需要合并 feature/xxx 分支 git merge --no-ff feature/xxx

在解釋這個命令之前，先解釋下 Git 中的 fast-forward： 舉例來說，開發(fā)一直在 develop 分支進(jìn)行，此時有個新功能需要開發(fā)，新建一個 feature/a 分支，并在其上進(jìn)行一系列開發(fā)和提交。當(dāng)完成功能開發(fā)時，此時回到 develop 分支，此時 develop 分支在創(chuàng)建 feature/a 分支之后沒有產(chǎn)生任何的 commit，那么此時的合并就叫做 fast-forward。

fast-forward 合并的結(jié)果如下圖所示，這種 merge 的結(jié)果就是一條直線了，無法明確看到切出一個新的 feature 分支，并完成了一個新的功能開發(fā)，因此此時比較推薦使用 git merge --no-ff，得到的結(jié)果就很明確知道，新的一系列提交是完成了一個新的功能，如果需要對這個功能進(jìn)行 code review，那么只需要檢視叉的那條線上的提交即可。

關(guān)于以上兩個分支間的操作建議。

2.3 項(xiàng)目分支操作流程示例

這部分內(nèi)容結(jié)合日常項(xiàng)目的開發(fā)流程，涉及到開發(fā)新功能、分支合并、發(fā)布新版本以及發(fā)布緊急修復(fù)版本等操作，展示常用的命令和操作。

• 切到 develop 分支，更新 develop 最新代碼

git checkout developgit pull --rebase

• 新建 feature 分支，開發(fā)新功能

git checkout -b feature/xxx...git add git commit -m "feat(xxx): commit a"git commit -m "feat(xxx): commit b"# 其他提交...

如果此時 develop 分支有一筆提交，影響到你的 feature 開發(fā)，可以 rebase develop 分支，前提是 該 feature 分支只有你自己一個在開發(fā)，如果多人都在該分支，需要進(jìn)行協(xié)調(diào)：

# 切換到 develop 分支并更新 develop 分支代碼git checkout developgit pull --rebase# 切回 feature 分支git checkout feature/xxxgit rebase develop# 如果需要提交到遠(yuǎn)端，且之前已經(jīng)提交到遠(yuǎn)端，此時需要強(qiáng)推(強(qiáng)推需慎重！)git push --force

上述場景也可以通過 git cherry-pick 來實(shí)現(xiàn)，有興趣的可以去了解一下這個指令。

• 完成 feature 分支，合并到 develop 分支

# 切到 develop 分支，更新下代碼git check developgit pull --rebase# 合并 feature 分支git merge feature/xxx --no-ff# 刪除 feature 分支git branch -d feature/xxx# 推到遠(yuǎn)端git push origin develop

• 當(dāng)某個版本所有的 feature 分支均合并到 develop 分支，就可以切出 release 分支，準(zhǔn)備發(fā)布新版本，提交測試并進(jìn)行 bug fix

# 當(dāng)前在 develop 分支git checkout -b release/xxx# 在 release/xxx 分支進(jìn)行 bug fixgit commit -m "fix(xxx): xxxxx"...

• 所有 bug 修復(fù)完成，準(zhǔn)備發(fā)布新版本

# master 分支合并 release 分支并添加 taggit checkout mastergit merge --no-ff release/xxx --no-ff# 添加版本標(biāo)記，這里可以使用版本發(fā)布日期或者具體的版本號git tag 1.0.0# develop 分支合并 release 分支git checkout developgit merge --no-ff release/xxx# 刪除 release 分支git branch -d release/xxx

至此，一個新版本發(fā)布完成。

• 線上出現(xiàn) bug，需要緊急發(fā)布修復(fù)版本

# 當(dāng)前在 master 分支git checkout master# 切出 hotfix 分支git checkout -b hotfix/xxx... 進(jìn)行 bug fix 提交# master 分支合并 hotfix 分支并添加 tag(緊急版本)git checkout mastergit merge --no-ff hotfix/xxx --no-ff# 添加版本標(biāo)記，這里可以使用版本發(fā)布日期或者具體的版本號git tag 1.0.1# develop 分支合并 hotfix 分支(如果此時存在 release 分支的話，應(yīng)當(dāng)合并到 release 分支)git checkout developgit merge --no-ff hotfix/xxx# 刪除 hotfix 分支git branch -d hotfix/xxx

至此，緊急版本發(fā)布完成。

3. 提交信息規(guī)范

git commit 格式 如下：

():

各個部分的說明如下：

• type 類型，提交的類別
• feat: 新功能
• fix: 修復(fù) bug
• docs: 文檔變動
• style: 格式調(diào)整，對代碼實(shí)際運(yùn)行沒有改動，例如添加空行、格式化等
• refactor: bug 修復(fù)和添加新功能之外的代碼改動
• perf: 提升性能的改動
• test: 添加或修正測試代碼
• chore: 構(gòu)建過程或輔助工具和庫(如文檔生成)的更改
• scope 修改范圍
• 主要是這次修改涉及到的部分，簡單概括，例如 login、train-order
• subject 修改的描述
• 具體的修改描述信息
• 范例

feat(detail): 詳情頁修改樣式fix(login): 登錄頁面錯誤處理test(list): 列表頁添加測試代碼

這里對提交規(guī)范加幾點(diǎn)說明：

type + scope 能夠控制每筆提交改動的文件盡可能少且集中，避免一次很多文件改動或者多個改動合成一筆。

subject 對于大部分國內(nèi)項(xiàng)目而已，如果團(tuán)隊(duì)整體英文不是較高水平，比較推薦使用中文，方便閱讀和檢索。

避免重復(fù)的提交信息，如果發(fā)現(xiàn)上一筆提交沒改完整，可以使用 git commit --amend 指令追加改動，盡量避免重復(fù)的提交信息。

總結(jié)

以上是生活随笔為你收集整理的项目中使用粘性布局不起作用_项目中的 Git 使用规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。