Как называть ветки в git

Правильное именование веток

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

Отслеживать
28.8k 12 12 золотых знаков 59 59 серебряных знаков 118 118 бронзовых знаков
задан 4 фев 2017 в 14:48
RapperOfCodings RapperOfCodings
331 1 1 золотой знак 4 4 серебряных знака 4 4 бронзовых знака
есть ли не слышали о подобных шаблонах, напишите как обычно вы их называете или дайте пару советов.
4 фев 2017 в 14:54
git-flow (описан в ответе @Evgeniy), github-flow, gitlab-flow.
4 фев 2017 в 15:20
@Arhad добавил про gitlab-flow.
4 фев 2017 в 15:51
Допустим, кто-нибудь ещё про github-flow допишет, и какой тогда ответ отмечать верным?)
4 фев 2017 в 18:29

3 ответа 3

Сортировка: Сброс на вариант по умолчанию

Git Flow

Основные ветки

Ветки master и develop считаются основными ветками, их смысл состоит в том, что они существуют до тех пор, пока существует сам проект. В ветке master всегда хранится стабильная версия проекта (релиз), в ветке develop хранится текущая рабочая версия проекта.

Вспомогательные ветки

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

Используются следующие типы веток:

• Ветки функциональностей (Feature branches) Ветки функциональностей могут иметь произвольные названия, которые очень кратко описывают суть задачи, для которой они создаются. Порождается от ветки develop и используются для внедрения в проект дополнительных функций (фич), после чего вливается обратно в develop .
• Ветки релизов (Release branches) Название имеет вид release-* . Когда появляется надобность в новом релизе, создаётся ветка релиза, происходящая от develop , в которой происходят косметические изменения, необходимые для релиза. После этого ей присваивается версия (тег) в соответствии с принятым в компании стандарте нумераций версий и она вливается в обе основные ветки, master и develop .
• Ветки исправлений (Hotfix branches) Название имеет вид hotfix-* . Если в текущей стабильной версии проекта (которая хранится в master ) выявляется баг, который требует немедленного исправления, создаётся ветка багфикса (исправления), порождённая от master . После удачного исправления бага вливается в master и develop .

Отслеживать
28.8k 12 12 золотых знаков 59 59 серебряных знаков 118 118 бронзовых знаков
ответ дан 4 фев 2017 в 15:19
729 6 6 серебряных знаков 21 21 бронзовый знак
Дооформите до полноценного описания Git Flow по аналогии с соседним ответом что ли)
4 фев 2017 в 18:19
Про patch-1 ещё можно упомянуть — ветке для pull request. Спасибо за ответ.
4 фев 2017 в 19:32
@СашаЧерных необязательно ветка для пулл-реквеста так называется. Из любой ветки можно открыть ПР.
4 фев 2017 в 20:31

Автор, вы в последней версии просто скопировали текст с хабра с незначительными изменениями. Это как минимум не допускается лицензией хабра. И называется «плагиат». Предлагаю вам вместо этого написать свой текст.

5 фев 2017 в 0:08
@NickVolynkin хмм.. не знал про лицензию хабра. Спасибо за совет, сейчас перепишу.
5 фев 2017 в 18:16

GitLab Flow

GitLab Flow даёт достаточно подробные рекомендации по именованию веток.

Стабильные ветки

Стабильные (долгоживущие, stable, long-living) ветки именуются соответственно окружениям (environments), на которые разворачивается (deploy) код из последнего коммита этой ветки. Исключение делается для ветки master , которая разворачивается на staging, либо сразу на production.

 → : master → staging («предпоследний рубеж» тестирования, интеграционные тесты) pre-production → pre-production («последний рубеж», бета-тестеры и приёмка) production → production (то, что мы предоставляем клиентам) 

Это правило даёт максимальный эффект, когда вы настраиваете автоматическое развертывание приложения в соответствующую среду. То есть:

• Появление нового коммита в ветке master означает, что у вас появился новый релиз-кандидат, который идёт на staging . Там на нём должны запускаться интеграционные тесты, там на него смотрит менеджер продукта и/или заказчик, там его тыкают бета-тестеры и т.п.
• Появление нового коммита в production означает релиз очередной версии. Поскольку у коммита есть дата и автор, вы всегда будете знать, кто и когда принял решение о релизе.
• Вы всегда знаете, какая версия кода находится в каждом из окружений. Если где-то обнаружен баг (хорошо, когда не на продакшене), не составит труда найти содержащую его версию.
• Разумеется, ветки нужно защищать, чтобы выпускать релизы мог только ответственный за это человек.

Версионные ветки

Если вы выпускаете поддерживаемые версии продукта, используйте для них версионные ветки (version branches) с единообразными именами, содержащими номер версии и некоторый идентификатор версионной ветки, например:

1-2-stable 1-3-stable 

Ветки фич

Для решения конкретных задач из трекера (системы учета задач) используются отдельные ветки фич (feature branches). У каждой задачи есть номер и название (заголовок). Соответственно, ветка для этой задачи должна иметь вид:

То есть, если в нашем трекере есть две задачи:

1. Make hello world
2. Write readme

То соответствующие ветки должны называться:

1-make-hello-world 2-write-readme 

Если заголовки задач у вас в кириллице или любом другом не-ASCII алфавите, то, пожалуй, названия веток лучше переводить. Наверное, можно и транслит использовать, но мне кажется, что его сложно читать. На этот счёт в GitLab Flow нет конкретного правила, поэтому вам нужно самостоятельно выработать внутрикомандное правило. Тут допустимы вольности, потому что вы всегда можете точно сопоставить ветку с задачей по их номеру.

Отслеживать
ответ дан 4 фев 2017 в 15:51
Nick Volynkin ♦ Nick Volynkin
34k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака

Если заголовки задач у вас в кириллице, то имена веток можно давать кириллицей. Хз зачем, но в гит это работает.

7 июн 2017 в 16:42

GitHub flow

По сравнению с другими вариантами, GitHub Flow проще, но и ограниченнее.

Он неплох для хорошо дисциплинированных команд, способных выпускать в продакшн каждую фичу сразу по мере готовности без серьёзных поломок. Это требует хорошего автоматического QA/QC и/или стальных нервов.

В нём ветки делятся на две категории:

• Единственная стабильная ветка master , содержащая последнюю стабильную версию, готовую к разворачиванию в любой момент.
• Ветки фич, для pull request’ов в master , названные таким образом, чтобы можно было догадаться, о чём фича. Средствами гитхаба обычно настраивается ряд проверок для каждого pull request’а, успешное прохождение которых удостоверяет, что принятие ничего не поломает. Этими проверками может быть инспекция кода (code review), запуск тестов или даже развёртывание на временную среду, где с результатом может поиграть кто угодно.
  В теории, можно ещё делать pull request’ы к pull request’ам, при работе над особо крупными вещами, которые надо принимать только целиком или не принимать вообще. Но на практике я с таким не сталкивался.
  Примеры названий веток, приводимые самим гитхабом:
  • refactor-authentication
  • user-content-cache-key
  • make-retina-avatars

  Всё. Больше ничего нет. Релизы обозначаются метками (tag), хотфиксы фактически приводят к новым релизам и, соответственно, новым меткам.

  Но из-за ограниченности и простоты, как правило, его расширяют.

  К примеру, по мере развития проекта обычно возникают версионные ветки. Скажем, если намечается группа версий, в которую придётся «бэкпортить» (backport, портировать на старую версию) новые фичи или исправления, то для неё можно создать свою именованную ветку, эту группу версий объединяющую, обычно по неполному номеру версии или маске:

  Как именовать ветки?

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

  • Вопрос задан более трёх лет назад
  • 10407 просмотров

  Комментировать
  Решения вопроса 3

  

  Solution Architect, AWS Certified, Serverless
  Ответ написан более трёх лет назад
  Комментировать
  Нравится 10 Комментировать

  

  Знаю больше чем это необходимо

  да как хотите. Назовите ветку для продакшена «production», для разработки «development», для фичи с логином пользователя через фейсбук «feature/facebook-login» никто не запутается.

  Все это зависит от проекта/размера/привычек команды/сложности/процесса разработки/процесса тестирования/схемы релизов и так далее.
  Единственное что есть более менее везде — это ветка master которая создается по дефолту и чаще всего ее и оставляют для продакшена. Но это тоже не всегда — бывает наоборот в мастере девелопмент а для релиза — релизные ветки.
  Еще часто используется «feature/name», «bug/name» и так далее для удобства, плюс некоторые гит клиенты умеют такие ветки в списке веток группировать между собой.

  Можно взять git-flow, если своего не придумывается ничего, но надо понимать что он предполагает определенную и достаточно жесткую структуру работы над проектом вообще, которая затрагивает не только названия веток но и вообще все аспекты цикла создания продукта.

  Git для начинающих. Урок 8.
  Ветки на сервере

  Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

  Просмотр веток на сервере

  • git branch выводит список локальных веток
  • git branch -r (remote) — список веток на сервере
  • git branch -a (all) — список всех веток, локальных и удаленных

  Удаленные ветки начинаются с remotes/origin/

   $ git branch master * news $ git branch -a master * news remotes/origin/master remotes/origin/news remotes/origin/students 

  Как отслеживать новые ветки на сервере

  Если мы в проекте не одни, то в нем будут постоянно появляться новые ветки. Но как их увидеть?

  Допустим, у нас в проекте есть только ветка master. В это время кто-то добавил новую ветку news. Просто git branch -a удаленные ветки не покажет

   $ git branch -a * master remotes/origin/master 

  Чтобы их увидеть, сначала нужно выполнить команду git fetch, которая сходит на сервер и проверит, что там есть нового

   $ git fetch remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:Webdevkin/site-git * [new branch] news -> origin/news 

  Мы видим, что появилась новая ветка news, и команда git branch -a это подтверждает

   $ git branch -a * master remotes/origin/master remotes/origin/news 

  Обратите внимание, ветка news появилась только в списке удаленных, но не локальных. То есть команда git fetch не создает локальные ветки, она просто подтягивает информацию о них. Чтобы переключиться на новую ветку, нужно выполнить git checkout

   $ git checkout news Branch news set up to track remote branch news from origin. Switched to a new branch 'news' 

  Вот теперь мы переключились на новую ветку

   $ git branch -a master * news remotes/origin/master remotes/origin/news 

  Как удалить ветку с сервера

  Выполняем пуш ветки, только с флагом —delete

   $ git push origin --delete news To git@github.com:Webdevkin/site-git.git - [deleted] news 

  Как работать с удаленными ветками в PhpStorm

  Точно так же, как и с локальными, только в списке Remote Branches. Чтобы увидеть новые ветки, тоже нужно выполнить команду fetch. Правый клик — Git — Repository — Fetch. А уже потом можно переключаться на эту ветку: Remote Branches — branch_name — Checkout as.

  Что могу посоветовать

  • регулярно просматривайте github — так вы будете лучше понимать, чем занимаются ваши коллеги
  • не забывайте делать git fetch перед переключением на удаленную ветку
  • обсудите с коллегами правила именования веток и соблюдайте их

  Я не в первый раз упоминаю про именование коммитов и веток. Если вы работаете один, то как называть — ваше дело. Но если работаете в команде, то несоблюдение каких-то правил могут привести примерно к этому

  

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

  На этом все. В следующем уроке мы поговорим о слиянии или мерджах веток.

  Спасибо за внимание и до встречи!

  Все уроки курса

  • Вводный урок
  • 1. Установка и базовая настройка git
  • 2. Создание и клонирование репозитория git
  • 3. Делаем первые изменения, git status и git diff
  • 4. Коммиты и история коммитов, git commit, git log и git show
  • 5. Подробнее об истории коммитов. Путешествие по истории
  • 6. Работа с сервером, git push и git pull
  • 7. Ветки — главная фишка git, git branch и git checkout
  • 8. Работа с ветками на сервере, git fetch
  • 9. Слияния или мерджи веток, git merge
  • 10. Конфликты и их разрешение
  • Платная часть курса. Презентация
  • * 11. Работа с gitignore и git exclude
  • * 12. Буфер обмена git, git stash
  • * 13. Копирование коммитов, git cherry-pick
  • * 14. Отмена и редактирование последнего коммита
  • * 15. Отмена произвольного коммита, git revert
  • 16. Склеивание коммитов, git rebase —interactive и git reflog
  • * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
  • * 18. Работа с git rebase. Отличия от merge
  • * 19. Что такое git push —force и как с ним работать
  • * 20. Ищем баги с помощью git, git bisect
  • * 21. Как и зачем работать с тегами git
  • * 22. Процессы: github flow и git flow
  • * 23. Псевдонимы в git
  • 24. Мердж-реквесты
  • * 25. Форки

  Работа с ветками в GIT

  Чтобы исправить баг или сделать новую фитчу в проекте, обычно создают новую ветку. Зачем? Чтобы избежать путаницы. Если бы все делалось в основной ветке, в проекте было бы сложно разобраться, особенно если над ним одновременно работает много людей.
  Поэтому только по окончании работы над задачей изменения в ветке сливают в основную ветку master.

  Создание ветки

  Чтобы создать новую ветку testing локально, выполним команду:

  $ git branch testing

  На момент выполнения команды вы находились в какой-то ветке, допустим в master. Состояние этой ветки будет скопировано в ветку testing, и в testing можно будет редактировать файлы и делать снимки, не трогая пока основную ветку master.

  Переключение на ветку

  Предыдущая команда создаст ветку, но не переключит нас на нее, мы все еще останемся работать в старой ветке. Чтобы перейти на ветку testing и начать работать в ней, выполним команду:

  $ git checkout testing

  Имейте в виду, что GIT не позволит перейти на другую ветку, если в текущей ветке — в которой мы находимся — есть изменения, которые не зафиксированы (commit) либо не спрятаны (stash). Это нормально, ведь при смене ветке в текущем каталоге сменятся файлы, и git-у надо знать, как быть с текущими изменениями.

  Создание и переключение единой командой

  Чтобы не выполнять предыдущие команды по очереди, можно написать их одной строкой:

  $ git checkout –b testing

  Эта команда создаст ветку testing и сразу переключит нас на нее. Обычно именно это и требуется сделать.

  Как переключиться на чью-то ветку из удаленного репозитория

  Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой — вы создаете локальную копию чужой ветки, и над ней уже работаете.

  Но для начала надо обновить локальный репозиторий — скопировать в него все ветки, которые есть в удаленном репозитории:

  git fetch

  Теперь можно посмотреть, какие ветки есть в удаленном репозитории:

  git branch -v -a

  Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:

  git checkout -b dev1 origin/dev1

  Вообще-то можно было написать проще:

  git checkout dev1

  1. Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
  2. Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:

  git checkout -b mydev1 origin/dev1

  Как создать подветку ветки

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

  Предыдущая команда, с помощью которой мы создавали ветку:

  $ git branch testing

  создает ответвление от основной ветки master.

  Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:

  $ git checkout testing $ git checkout -b subbranch_of_testing testing

  Первая команда переключит нас на ветку testing.
  Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
  Как понятно из имени, subbranch_of_testing – это подветка ветки testing.

  Как посмотреть ветки

  Чтобы увидеть все созданные локально ветки, выполним команду:

  $ git branch

  Появится список веток. Текущая ветка будет выделена звездочкой.

  Как переименовать ветку

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

  Локальную

  Если еще не выполнена команда push, то достаточно переименовать локальную ветку.

  Чтобы переименовать локальную ветку, выполним команду:

  $ git branch -m

  Например, переименуем ветку testing в ветку test:

  $ git branch –m testing test

  Чтобы переименовать текущую ветку, выполним команду:

  $ git branch -m

  Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:

  $ git branch –m subbranch

  Удаленную

  Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:

  $ git push origin :old-name new-name

  здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),
  old-name — имя ветки локальной ветки,
  new-name — новое имя ветки в удаленном репозитории.

  Например, надо переименовать ветку testing в test:

  $ git push origin :testing test

  Удаление локальной ветки

  Чтобы удалить локальную ветку, выполните одну из команд:

  $ git branch -d branch_name $ git branch -D branch_name

  Флаги:
  -D сокращение для —delete –force удаляет ветку независимо от того, слиты ли ее изменения
  -d сокращение для —delete
  Например, удалим локальную ветку test:

  $ git branch –d test

  Вообще-то локальную ветку обычно удаляют после того, как слили ее (выполнили merge) в ветку master, смотрите последний раздел в статье о слиянии веток.

  Удаление ветки из удаленного репозитория

  Чтобы удалить удаленную ветку, можно использовать две записи.
  Либо через двоеточие, как мы уже делали при переименовании ветки:

  $ git push origin :branch_name

  Например, удалим ветку test из удаленного репозитория origin:

  $ git push origin :test

  Либо с флагом —delete, так понятнее:

  $ git push origin --delete test

  здесь origin — имя удаленного репозитория

  Как слить ветки

  Обычно сливают некоторую ветку (например, ветку-багфикс) в ветку master. Для этого сначала перейдем в ветку master (в ту ветку, в которую вливаем изменения):

  $ git checkout master

  А затем выполним слияние. Допустим, в ветку master надо слить ветку test :

  $ git merge test

  Слияние веток не всегда происходит гладко, иногда требуется разрешить конфликты вручную. Для этого надо отредактировать конфликтые файлы, выполнить их commit.

  Итог

  В этой статье мы рассмотрели работу с ветками GIT и составили небольшую шпаргалку по использованию веток.

  Автор sysout Опубликовано 12.07.2018 11.07.2021 Рубрики Git

  Добавить комментарий Отменить ответ

  Прошу прощения: на комментарии временно не отвечаю.

  Похожие публикации:

  1. Ccleaner business edition или professional что лучше
  2. Как найти напряжение на выходе
  3. Как открыть шкоду рапид если сел аккумулятор
  4. Шумофф или stp что лучше