git-分支命名規範

git分支命名規範

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

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

群組標記(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 或分支名稱,並且,這讓我的選擇被受限。

避免長描述的名稱

當你正在分支清單尋找時,長分支名稱是有幫忙的。 But it can get in the way when looking at decorated one-line logs as the branch names can eat up most of the single line and abbreviate the visible part of the log.

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

小結

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

沒有留言:

張貼留言

感謝您的留言,如果我的文章你喜歡或對你有幫助,按個「讚」或「分享」它,我會很高興的。