git分支命名規範

在瞭解分支命名資料時，看到一篇StackoverFlow的git branch naming best practices討論，覺得解答者 phord 提供的建議非常不錯，簡單翻譯筆記一下。

分支開頭使用群組標記(grouping tokens)。
定義和使用簡短標記來區別分支結構對您的工作流是有意義的
使用斜線(斜杠)來分隔您的分支名稱部分
請不要使用純粹的數字作為主導部分
避免使用較長的描述性名稱為長生命週期的分支命名

群組標記(Group tokens)

使用群組標記在你的分支名稱，例如：

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

群組名稱只要符合你的工作流程即可，並無硬性規定。我喜歡用短的名詞。

簡短且明確定義的標記

選擇短標記的好處是，它們不會對你的分支增加太多噪音。我使用這些：

wip: 進行中的工作；我知道它不會很快完成
feat: 增加或擴充的功能
bug: Bug修復或實驗
junk: 可丟棄的實驗性分支。

每個標記可告訴你，你的分支屬於工作流程的那個部分。

這聽起來像你有一個不同變化週期的多個分支。我不知道你的週期是什麼，但是讓我們假設他們是“new”，“testing”和“verified”。您可以使用這些標籤的縮寫版本來命名分支，拼寫總是以同樣的方式，它們分組並提醒你是在哪個階段。

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

你可以快速知道那些分支已經達到不同的階段，你可以組輕鬆地使用Git的模式匹配選項來群組分類。

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo 

$ gitk --branches="*/foo"

使用斜線區分

你可以使用任何分隔符在你的分支名稱，但我覺得斜線是最靈活的。你可能更願意使用破折號或點。但是斜線讓你從遠端push或fetch分支時做一些重後命名。

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

對我而言，斜線在我的ZShell環境提供更好的Tab擴充(命令完成)。透過那樣的配置，我可以搜尋分支的不同部分，僅需要輸入第一個單字後並按下Tab鍵。Shell會返回符合部分的分支的清單。

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar

$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell關於命令完成的可配置性非常高，我也可以配置它以同樣的方式來處理破折號，下劃線或點。但我選擇不。)

它還允許你在許多的 git 指令中去搜尋分支，像這樣：

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*"
gitk --branches="feature/*"

警告：由於 Slipp 在評論中指出斜線可能導致問題。因為使用路徑來實現分支，不能有一個命名為"foo"和名為"foo/bar"的另一個分支的分支。這可能是令新使用者困惑。

不要使用純粹的數字

不要使用使用純粹的數字或十六進位(hex)數字作為您分支命名方案的一部分。當 Tab 擴展參考名稱時，git 可以決定一個數字是 SHA1 的一部分而不是分支名稱。例如，我的問題追蹤器(issue tracker)的bug名稱是十進位數字。我分支相關的名稱是以 CRnnnnn 而不是 nnnnn 以避免混淆。

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

如果我嘗試展開 15032, git 將會無法確定我們要搜尋 SHA1 或分支名稱，並且，這讓我的選擇被受限。

避免長描述的名稱

當你正在分支清單尋找時，長分支名稱是有幫忙的。

另一方面，如果你沒有習慣性地手動將"merge commits"改寫，長分支名稱可能有幫助。預設 merge commit 訊息是 Merge branch 'branch-name'。你也許能發現它更能說明合併訊息為 Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' 而不是 Merge branch 'fix/CR15032'。

小結

最後一小節的長描述說明，我搞不清楚是在說優點還是缺點 XD

KingKong Bruce記事

網頁