Каковы некоторые примеры часто используемых методов именования веток git?

Я использую локальный репозиторий git, взаимодействующий с моим репозиторием CVS группы в течение нескольких месяцев. Я сделал почти невротическое число ветвей, большинство из которых, к счастью, слились обратно в мой сундук. Но именование начинает становиться проблемой. Если у меня есть задача, которую легко назвать простой меткой, но я выполняю ее в три этапа, каждый из которых включает в себя свою собственную ветвь и ситуацию слияния, то я могу каждый раз повторять имя ветки, но это делает историю немного запутанной. Если я буду более конкретным в именах, с отдельным описанием для каждого этапа, то имена ветвей начинают становиться длинными и громоздкими.

Я действительно изучал, просматривая старые темы здесь, что я мог начать именовать ветки с именем/в имени, т.е. темой/задачей или что-то в этом роде. Я могу начать делать это и видеть, помогает ли это лучше организовывать вещи.

Каковы некоторые рекомендации по наименованию ветвей git?

Изменить: На самом деле никто не предлагал никаких соглашений об именах. Я удаляю ветки, когда я с ними работаю. У меня просто бывает несколько факторов из-за того, что руководство постоянно корректирует мои приоритеты.:) В качестве примера того, почему мне может понадобиться несколько ветвей для задачи, предположим, что мне нужно перенести первую дискретную веху в задачу в репозиторий CVS группы. В этот момент, из-за моего несовершенного взаимодействия с CVS, я выполнил бы эту фиксацию, а затем убью эту ветку. (Я видел слишком много странностей, взаимодействующих с CVS, если я попытаюсь продолжать использовать ту же ветвь в этой точке.)

Ответ 1

Вот некоторые соглашения об именах веток, которые я использую, и причины для них

Соглашения о присвоении имен ветким

  • Используйте значки группировки (слова) в начале имен ваших ветвей.
  • Определите и используйте короткие токены для того, чтобы различать ветки таким образом, который имеет смысл для вашего рабочего процесса.
  • Используйте косые черты для разделения частей имен ваших веток.
  • Не используйте голые числа в качестве ведущих частей.
  • Избегайте длинных описательных имен для долгоживущих ветвей.

Групповые жетоны

Используйте "группировать" токены перед именами ваших веток.

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". Это может ввести в заблуждение для новых пользователей.

Не использовать голые числа

Не используйте использование голых чисел (или шестнадцатеричных чисел) как часть схемы именования веток. Внутри расширений tab-расширения ссылочного имени 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'.

Ответ 2

У успешной модели ветвления Git Винсента Дриссена есть хорошие предложения. Картинка ниже. Если вам подходит эта модель ветвления, рассмотрите расширение потока для git. Другие прокомментировали поток

Модель Driessen включает в себя

  • Основная ветка, используемая только для релиза. Типичное имя master.

  • "Развивающийся" филиал этого ветки. Это тот, который используется для большинства основных работ. Обычно называют develop.

  • Многофункциональные ветки развивающейся ветки. Имя основано на названии функции. Они будут объединены обратно в развитие, а не в основную ветку или ветки выпуска.

  • Релиз ветки для хранения кандидатских релизов, только с исправлениями ошибок и без новых функций. Типичное название rc1.1.

Исправления - это кратковременные ветки для изменений, которые приходят от мастера и будут переходить в мастер без участия ветки разработки.

enter image description here

Ответ 3

Мое личное предпочтение - удалить имя ветки после Im с веткой темы.

Вместо того, чтобы пытаться использовать имя ветки для объяснения значения ветки, я начинаю строку темы сообщения фиксации в первой фиксации в этой ветке с помощью "Ветка:" и включаю дополнительные пояснения в теле сообщения если субъект не дает мне достаточно места.

Имя ветки в моем использовании - это просто дескриптор для обращения к ветки темы при работе над ней. Как только работа над ветвью темы завершилась, я избавляюсь от имени ветки, иногда помечая фиксацию для последующей ссылки.

Это делает вывод git branch более полезным: он отображает только долговечные ветки и активные ветки тем, а не все ветки.

Ответ 4

Я смешивал и сопоставлял различные схемы, которые я видел, и основываясь на инструментах, которые я использую. Таким образом, мое завершенное имя ветки будет:

имя/функция/проблемно-трекер номер/короткое описание

который переводится на:

микрофон/блоги/RSSI-12/логотип затруднительного

Детали разделяются с помощью косой черты, потому что они получают интерпретацию как папки в SourceTree для упрощения организации. Мы используем Jira для отслеживания проблем, поэтому включение номера упрощает поиск в системе. В том числе это число также делает его доступным для поиска при попытке найти эту проблему внутри Github при попытке отправить запрос на перенос.

Ответ 5

Почему для каждой задачи требуется три ветки/слияния? Можете ли вы объяснить об этом больше?

Если вы используете систему отслеживания ошибок, вы можете использовать номер ошибки как часть имени ветки. Это приведет к тому, что имена ветвей будут уникальными, и вы можете префикс их коротким и описательным словом или двумя, чтобы они были удобными для чтения, например "ResizeWindow-43523". Это также помогает облегчить работу, когда вы идете на очистку веток, так как вы можете найти связанную с этим ошибку. Вот как я обычно называю свои ветки.

Поскольку эти ветки в конечном итоге сливаются обратно в мастера, вы должны быть безопасно удалять их после слияния. Если вы не сливаетесь с --squash, вся история ветки будет существовать, если вам когда-нибудь понадобится.

Ответ 6

Обратите внимание, как показано в commit e703d7 или commit b6c2a0d (март 2014 г.), теперь часть Git 2.0, вы найдете другое соглашение об именах (которое можно применить к ветвям).

"Когда вам нужно использовать пространство, используйте тире" - это странный способ сказать, что вы не должны использовать пробел.
Поскольку в описаниях командной строки более часто используются прерывистые многословные слова, вы даже не хотите использовать пробелы в этих местах.

Название ветки не может иметь место (см. "Какие символы являются незаконными в имени ветки?" и git check-ref-format man).

Итак, для каждого имени ветки, которое будет представлено многословным выражением, использование "-" (тире) в качестве разделителя является хорошей идеей.

Ответ 7

Следуя предложению farktronix, мы использовали номера билетов Jira для аналогичных в mercurial, и я планирую продолжить их использование для ветвей git. Но я думаю, что номер билета, вероятно, достаточно уникален. Хотя было бы полезно иметь описательное слово в названии ветки, как отметил farktronix, если вы часто переключаетесь между ветвями, вам, вероятно, нужно меньше вводить текст. Затем, если вам нужно знать имя ветки, посмотрите в Jira на соответствующие ключевые слова в билете, если вы этого не знаете. Кроме того, вы должны указать номер билета в каждом комментарии.

Если ваша ветка представляет собой версию, кажется, что общим соглашением является использование формата xxx (пример: "1.0.0" ) для имен ветвей и vx.xx(пример "v1.0.0" ) для имен тегов (to избегать конфликтов). См. Также: is-there-an-standard-naming-convention-for-git-tags