Ось деякі угоди про іменування галузей, які я використовую, та причини їх використання
Конвенції про іменування гілок
- Використовуйте групування лексем (слів) на початку назв вашої гілки.
- Визначте та використовуйте короткі жетони свинцю, щоб розмежувати гілки таким чином, що має значення для вашого робочого процесу.
- Використовуйте косої риси для відокремлення частин назв філій.
- Не використовуйте голі номери в якості провідних деталей.
- Уникайте довгих описових назв для довгоживучих гілок.
Групуйте жетони
Використовуйте "групування" жетонів перед іменами вашої філії.
group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz
Групи можна назвати, як вам завгодно, щоб відповідати вашому робочому процесу. Мені подобається вживати короткі іменники для мого. Читайте далі для більшої ясності.
Короткі чітко виражені лексеми
Виберіть короткі жетони, щоб вони не додавали занадто багато шуму кожному вашому імені філії. Я використовую ці:
wip Works in progress; stuff I know won't be finished soon
feat Feature I'm adding or expanding
bug Bug fix or experiment
junk Throwaway branch created to experiment
Кожен з цих жетонів може використовуватись для того, щоб визначити, до якої частини робочого процесу належить кожна гілка.
Здається, у вас є кілька гілок за різні цикли зміни. Я не знаю, які ваші цикли, але припустимо, що вони "нові", "тестування" та "перевірені". Ви можете назвати свої гілки за скороченими версіями цих тегів, які завжди написані однаково, як їх групувати, так і нагадувати, на якому етапі ви перебуваєте.
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"
Використовуйте косі риски для окремих частин
Ви можете використовувати більшість розділювачів, які вам подобаються, у назвах гілок, але я вважаю косої риси найбільш гнучкими. Ви можете скористатися тире або крапками. Але косої риски дозволяють вам перейменувати гілку під час натискання або отримання з / з віддаленого пристрою.
$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'
Для мене штрихи також краще працюють для розширення вкладок (завершення команди) в моїй оболонці. У налаштованому режимі я можу шукати гілки з різними підрозділами, ввівши перші символи частини та натиснувши клавішу TAB. Потім Zsh дає мені список гілок, які відповідають тій частині токена, яку я набрав. Це працює як для попередніх жетонів, так і для вбудованих.
$ 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/*"
Застереження: як в коментарях зауважує Сліпп, косі риски можуть спричинити проблеми. Оскільки гілки реалізовані як шляхи, ви не можете мати гілку з назвою "foo" та іншу гілку з назвою "foo / bar". Це може заплутати нових користувачів.
Не використовуйте голі номери
Не використовуйте голові номери (або шістнадцяткові номери) як частину схеми іменування вашої гілки. Всередині вкладки-розширення посилального імені git може вирішити, що число є частиною sha-1 замість імені гілки. Наприклад, мій трекер випуску називає помилки з десятковими числами. Я називаю свої споріднені гілки CRnnnnn, а не просто nnnnn, щоб уникнути плутанини.
$ git checkout CR15032<TAB>
Menu: fix/CR15032 test/CR15032
Якби я спробував розширити лише 15032, git був би не впевнений, чи хочу я шукати назви SHA-1 або гілки, і мій вибір був би дещо обмежений.
Уникайте довгих описових імен
Довгі назви гілок можуть бути дуже корисними, коли ви переглядаєте список гілок. Але це може заважати, дивлячись на декоровані однорядкові журнали, оскільки назви гілок можуть з'їдати більшу частину одного рядка та скоротити видиму частину журналу.
З іншого боку, довгі назви гілок можуть бути кориснішими для "об'єднання комітетів", якщо ви не звично переписуєте їх вручну. За замовчуванням повідомлення про злиття є Merge branch 'branch-name'. Вам може бути корисніше, щоб повідомлення про злиття відображалися як Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'просто Merge branch 'fix/CR15032'.
