乾貨：基於 Git Flow 的 Git 最佳實踐

知識 07-23

突然想寫這一篇Git的使用心得，主要有幾個原因，其一是自己使用Git也有快3年時間了，其間自己經歷過一些坑，也有迷茫的時候，在呆過的大大小小的團隊中，其實每個人也都並不是Git專家，很多對於流程以及Git本身的理解，還處於一個比較混亂的地帶。自己寫這篇文章希望能拋磚引玉，在總結自己得失的同時，能給大家帶來更深層次的思考。

直接進入主題，經過這麼多年的實踐，多次想避開Git flow尋找更簡單的流程，每次自認為找到了捷徑，但事實上都發現有這樣或者那樣更多的問題，所以，我認為最佳的Git實踐，仍然得基於標準的Git Flow，來看看Git Flow的標準模型，下面是大家非常熟悉的圖：

基於這個Git Flow，我所認為的Git 最佳實踐，補充和修復了這麼幾點：

1.分支一共有5類，名稱用 / 來區分是因為Sourcetree裡面 / 可以作為一個文件夾使用，命名標準為下面這樣：

master

develop

feature/***

release/v13.5

hotfix/v13.2

本地的分支可以有一些其他的命名規則，沒關係，但是推到遠程的必須是這幾種命名規範，最好一字不差，比如不要把release寫成Release

2.此Git Flow唯一可以變通的地方為開發的時候非必須一定要用feature分支，比如說一個項目剛開始開發的時候，或者突然發現一個不是特別嚴重的bug，我現在先修改下，想在下一個版本發的時候一起帶出去，這種情況就在develop上面改就行了。

3.與Git Flow的論文略微不同，我倡導的是：一個版本開發完成，需要提測的時候，由各個feature合併到develop，然後在develop上開發自測，修復bug，正式提測的時候，由develop遷出release分支，提測

我個人認為這是一個非常良好的開發模型，伸縮性強，適用於各個規模的開發團隊，一個人開發，我也會這麼干，20個人的團隊，也是沒有任何問題的。關於這個模型，如果有任何疑問，都可以關注我的公眾號（文章底部），然後給我發消息，我會一一解答。

還有關於之前收集網友的很多問題和疑問，我在這裡一一回答下：

1，最經常問的，為什麼忽略文件無效

因為Git的忽略文件沒有辦法對已經納入版本庫的文件生效，解決辦法：gitignore裡面添加完之後，把本地文件刪了，然後commit，push上去，別人再更新，就OK了，下次還有這種類型的文件，就直接忽略了

2，Git可以添加項目中的文件夾許可權控制嗎

不行，問這個問題的原因是因為很多人把svn的思維搬到Git上來，Git並不是以文件夾為單位來組織的，所以現在大多數公司中UI的圖片等資源，像png，psd等文件都是用的svn管理，代碼用Git管理。想要用這種許可權控制的話，很多人另闢捷徑選擇用Git的子模塊和子數來處理，我感覺也是不太好

3，關於Git客戶端

我認為就兩種選擇，命令行和Sourcetree等全局的客戶端軟體，TortoiseGit根本不適用，原因就是Git不是以文件夾為組織單位的，Tortoise是依託於文件管理器的操作，所以不對付。然後就是各種IDE的插件，很多人用，我個人也是不喜歡，原因很簡單，Git是一種生活方式，並不只是在項目中用用而已

4，關於Git代碼分支回滾

暴力派reset：

本地的分支先（reset）重置到一個commit，然後：git push -f，強推，這種是屬於刪除commit歷史的行為，而且強推需要許可權，一般來說master分支默認都不讓強推

優點：徹底清除版本庫上無用的代碼，乾淨，但是做這種操作的同時，最好本地新建一個分支備份下代碼

缺點：誤操作的代價比較大

婉約派revert：

git revert HEAD~1（1代表從0到1，回退包含當前commit的兩個commit，然後會創建新的commit）

優點：所有歷史都在，回退的做法為新建一個commit來回滾之前幾個commit的代碼

缺點：回退幾個commit這個需要手動計算，比較煩

5，cherry pick合併單個提交

cherry pick不能完全合併單個commit，因為每個commit都是建立在前一個commit之上。