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
沒有留言:
張貼留言
感謝您的留言，如果我的文章你喜歡或對你有幫助，按個「讚」或「分享」它，我會很高興的。