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

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

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

Каковы некоторые рекомендации для именования веток Git?

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

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

Соглашения об именах филиалов

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

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

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

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 может решить, что число является частью ша-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'.

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

Модель Дриссена включает в себя

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

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

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

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

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

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

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

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

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

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

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

что бы перевести на:

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

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

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

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

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

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

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

Имя ветви не может содержать пробел (см. « Какие символы недопустимы в имени ветви? » И git check-ref-formatсправочную страницу ).

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

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

Если ваша ветвь представляет версию, кажется, что общепринятым условием является использование формата xxx (пример: "1.0.0") для имен ветвей и vx.xx (пример "v1.0.0") для имен тегов (чтобы избежать конфликта) , См. Также: есть ли там стандартное соглашение об именах для git-тегов