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

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

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

Отслеживать
28.5k 12 12 золотых знаков 58 58 серебряных знаков 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.5k 12 12 золотых знаков 58 58 серебряных знаков 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). У каждой задачи есть номер и название (заголовок). Соответственно, ветка для этой задачи должна иметь вид:

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

Make hello world
Write readme

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

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

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

Отслеживать
ответ дан 4 фев 2017 в 15:51
Nick Volynkin ♦ Nick Volynkin
33.9k 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, портировать на старую версию) новые фичи или исправления, то для неё можно создать свою именованную ветку, эту группу версий объединяющую, обычно по неполному номеру версии или маске:

3.1 Ветвление в Git — О ветвлении в двух словах

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

Некоторые люди, говоря о модели ветвления Git, называют её «киллер-фича», что выгодно выделяет Git на фоне остальных систем контроля версий. Что в ней такого особенного? Ветвление Git очень легковесно: операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро. В отличие от многих других систем контроля версий, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. Понимание и владение этой функциональностью дает вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки.

О ветвлении в двух словах

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

Как вы можете помнить из Что такое Git?, Git не хранит данные в виде последовательности изменений, он использует набор снимков (snapshot).

Когда вы делаете коммит, Git сохраняет его в виде объекта, который содержит указатель на снимок (snapshot) подготовленных данных. Этот объект так же содержит имя автора и email, сообщение и указатель на коммит или коммиты непосредственно предшествующие данному (его родителей): отсутствие родителя для первоначального коммита, один родитель для обычного коммита, и несколько родителей для результатов слияния двух и более веток.

Предположим, у вас есть каталог с тремя файлами и вы добавляете их все в индекс и создаёте коммит. Во время индексации вычисляется контрольная сумма каждого файла (SHA-1 как мы узнали из Что такое Git?), затем каждый файл сохраняется в репозиторий (Git называет такой файл блоб — большой бинарный объект), а контрольная сумма попадёт в индекс:
```
$ git add README test.rb LICENSE $ git commit -m 'Initial commit'
```
Когда вы создаёте коммит командой git commit , Git вычисляет контрольные суммы каждого подкаталога (в нашем случае, только основной каталог проекта) и сохраняет его в репозитории как объект дерева каталогов. Затем Git создаёт объект коммита с метаданными и указателем на основное дерево проекта для возможности воссоздать этот снимок в случае необходимости.

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

Рисунок 9. Коммит и его дерево

Если вы сделаете изменения и создадите ещё один коммит, то он будет содержать указатель на предыдущий коммит.

Рисунок 10. Коммит и его родители

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

Примечание

Ветка «master» в Git — это не какая-то особенная ветка. Она точно такая же, как и все остальные ветки. Она существует почти во всех репозиториях только лишь потому, что её создаёт команда git init , а большинство людей не меняют её название.

Рисунок 11. Ветка и история коммитов

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

Что же на самом деле происходит при создании ветки? Всего лишь создаётся новый указатель для дальнейшего перемещения. Допустим вы хотите создать новую ветку с именем testing . Вы можете это сделать командой git branch :
```
$ git branch testing
```
В результате создаётся новый указатель на текущий коммит.

Рисунок 12. Две ветки указывают на одну и ту же последовательность коммитов

Как Git определяет, в какой ветке вы находитесь? Он хранит специальный указатель HEAD . Имейте ввиду, что в Git концепция HEAD значительно отличается от других систем контроля версий, которые вы могли использовать раньше (Subversion или CVS). В Git — это указатель на текущую локальную ветку. В нашем случае мы всё ещё находимся в ветке master . Команда git branch только создаёт новую ветку, но не переключает на неё.

Рисунок 13. HEAD указывает на ветку

Вы можете легко это увидеть при помощи простой команды git log , которая покажет вам куда указывают указатели веток. Эта опция называется —decorate .
```
$ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9 Initial commit
```
Здесь можно увидеть указывающие на коммит f30ab ветки: master и testing .

Переключение веток

Для переключения на существующую ветку выполните команду git checkout . Давайте переключимся на ветку testing :
```
$ git checkout testing
```
В результате указатель HEAD переместится на ветку testing .

Рисунок 14. HEAD указывает на текущую ветку

Какой в этом смысл? Давайте сделаем ещё один коммит:
```
$ vim test.rb $ git commit -a -m 'made a change'
```
Рисунок 15. Указатель на ветку HEAD переместился вперёд после коммита

Интересная ситуация: указатель на ветку testing переместился вперёд, а master указывает на тот же коммит, где вы были до переключения веток командой git checkout . Давайте переключимся назад на ветку master :
```
$ git checkout master
```
Примечание
git log не показывает все ветки по умолчанию

Если выполнить команду git log прямо сейчас, то в её выводе только что созданная ветка «testing» фигурировать не будет.

Ветка никуда не исчезла; просто Git не знает, что именно она вас интересует, и выводит наиболее полезную по его мнению информацию. Другими словами, по умолчанию git log отобразит историю коммитов только для текущей ветки.

Для просмотра истории коммитов другой ветки необходимо явно указать её имя: git log testing Чтобы посмотреть историю по всем веткам — выполните команду с дополнительным флагом: git log —all .

Рисунок 16. HEAD перемещается когда вы делаете checkout

Эта команда сделала две вещи: переместила указатель HEAD назад на ветку master и вернула файлы в рабочем каталоге в то состояние, на снимок которого указывает master . Это также означает, что все вносимые с этого момента изменения будут относиться к старой версии проекта. Другими словами, вы откатили все изменения ветки testing и можете продолжать в другом направлении.

Примечание
Переключение веток меняет файлы в рабочем каталоге

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

Давайте сделаем ещё несколько изменений и создадим очередной коммит:
```
$ vim test.rb $ git commit -a -m 'made other changes'
```
Теперь история вашего проекта разошлась (см Разветвлённая история). Вы создали ветку и переключились на неё, поработали, а затем вернулись в основную ветку и поработали в ней. Эти изменения изолированы друг от друга: вы можете свободно переключаться туда и обратно, а когда понадобится — объединить их. И всё это делается простыми командами: branch , checkout и commit .

Рисунок 17. Разветвлённая история

Все описанные действия можно визуализировать с помощью команды git log . Для отображения истории коммитов, текущего положения указателей веток и истории ветвления выполните команду git log —oneline —decorate —graph —all .
```
$ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Made other changes | * 87ab2 (testing) Made a change |/ * f30ab Add feature #32 - ability to add new formats to the central interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9 initial commit of my project
```
Ветка в Git — это простой файл, содержащий 40 символов контрольной суммы SHA-1 коммита, на который она указывает; поэтому операции с ветками являются дешёвыми с точки зрения потребления ресурсов или времени. Создание новой ветки в Git происходит так же быстро и просто как запись 41 байта в файл (40 знаков и перевод строки).

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

Давайте посмотрим, почему и вам имеет смысл делать так же.

Примечание
Одновременное создание новой ветки и переключение на неё

Как правило, при создании новой ветки вы хотите сразу на неё переключиться — это можно сделать используя команду git checkout -b .

Примечание

Начиная с Git версии 2.23, вы можете использовать git switch вместо git checkout , чтобы:
- Переключиться на существующую ветку: git switch testing-branch .
- Создать новую ветку и переключиться на неё: git switch -c new-branch . Флаг -c означает создание, но также можно использовать полный формат:` —create`.
- Вернуться к предыдущей извлечённой ветке: git switch — .
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

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

Разработка функций в изолированной среде позволяет также создавать запросы pull для обсуждения ветки. Благодаря этому другие разработчики могут утвердить функцию до ее интеграции в официальный проект. Кроме того, если в середине проекта работа замедлится, можно создать запрос pull и попросить совета у коллег. В целом запросы pull существенно облегчают комментирование работы в команде.

Составной рабочий процесс Git с функциональными ветками может использоваться другими высокоуровневыми рабочими процессами Git, которые рассматриваются на странице обзора рабочих процессов Git. Рабочий процесс Git с функциональными ветками ориентирован на модель ветвления кода и представляет собой концепцию создания веток и управления ими. Другие рабочие процессы больше ориентированы на работу с репозиторием. Рабочий процесс Git с функциональными ветками можно интегрировать в другие рабочие процессы. В частности рабочий процесс Gitflow и рабочий процесс Git с форками традиционно используют рабочий процесс Git с функциональными ветками в своих моделях ветвления кода.

Порядок действий

В рабочем процессе с функциональными ветками используется центральный репозиторий, а ветка main отражает официальную историю проекта. Вместо создания коммитов напрямую в локальной ветке main , разработчики создают новую ветку каждый раз при начале работы над новой функцией. Функциональные ветки должны иметь описательные имена (например, «анимированные-элементы-меню» или «задача-1061»). Каждая ветка должна быть предназначена строго для одной цели. Технически Git не различает ветку main и функциональные ветки, поэтому в рамках функциональных веток разработчики могут редактировать, индексировать файлы и фиксировать их изменения в виде коммитов.

Кроме того, функциональные ветки можно (и нужно) отправлять в центральный репозиторий. Это позволяет работать над функцией совместно с другими разработчиками, не затрагивая официальный код. Поскольку main — это единственная «особая» ветка, хранение нескольких функциональных веток в центральном репозитории не представляет сложностей. Разумеется, это еще и удобный способ резервного копирования локальных коммитов. Ниже приводится пошаговый обзор жизненного цикла функциональной ветки.

Начните с ветки main

Все функциональные ветки создаются на основе актуального кода проекта. Подразумевается, что он обрабатывается и обновляется в ветке main .

Связанные материалы

Расширенный журнал Git

СМ. РЕШЕНИЕ

Изучите Git с помощью Bitbucket Cloud
```
git checkout main
git fetch origin 
git reset --hard origin/main
```
Шаг 1. Создайте репозиторий

Эта команда переключает репозиторий на ветку main , получает последние коммиты и сбрасывает локальную копию ветки main , чтобы она соответствовала последней версии.

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

Используйте отдельную ветку для каждой функции или задачи, над которой вы работаете. После создания ветки переключитесь на нее локально, чтобы все внесенные изменения сохранялись в ней.
```
git checkout -b new-feature
```
Эта команда выполняет переключение на ветку new-feature, основанную на ветке main . Флаг -b указывает Git на необходимость создания ветки, если она еще не существует.

Обновление, добавление, коммит и отправка изменений

В этой ветке можно выполнять редактирование, индексирование и отправку изменений обычным способом, используя неограниченное количество коммитов для формирования функции. Работайте над этой функцией и делайте необходимые коммиты, как обычно при использовании Git. Завершив работу, отправьте коммиты, чтобы обновить функциональную ветку в Bitbucket.
```
git status
git add 
git commit
```
Отправка функциональной ветки в удаленный репозиторий

Желательно отправлять функциональную ветку в центральный репозиторий. Это удобный способ резервного копирования при совместной работе с другими разработчиками: так они получают возможность просматривать коммиты в новой ветке.
```
git push -u origin new-feature
```
Эта команда отправляет ветку new-feature в центральный репозиторий (origin), и она посредством флага -u добавляется в качестве удаленной отслеживаемой ветки. После настройки отслеживаемой ветки можно вызвать git push без параметров для автоматической отправки ветки new-feature в центральный репозиторий. Для получения отзыва о новой функциональной ветке создайте запрос pull в системе управления репозиториями, например в Bitbucket Cloud или Bitbucket Data Center. Затем можно добавить проверяющих и убедиться, что все работает правильно, прежде чем выполнять слияние.

Исправление функции по отзывам

На этом этапе коллеги комментируют и утверждают отправленные коммиты. Исправьте функцию по их отзывам локально, а затем сделайте коммит и отправьте рекомендованные изменения в Bitbucket. Обновления отобразятся в запросе pull.

Слияние запроса pull

Если другие пользователи вносили изменения в репозиторий, перед слиянием может потребоваться разрешение конфликтов слияния. Если ваш запрос pull подтвержден и не содержит конфликтов, вы можете добавить код в ветку main . Выполните слияние из запроса pull в Bitbucket.

Запросы pull

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

Главное преимущество запросов pull — возможность проверки кода, но изначально они были задуманы как способ обсуждения кода. Запрос pull можно использовать для обсуждения конкретной ветки на раннем этапе в процессе разработки. Например, если разработчику требуется помощь с определенной функцией, достаточно отправить запрос pull. Заинтересованные стороны автоматически получат уведомление и смогут просмотреть вопрос разработчика рядом с соответствующими коммитами.

После принятия запроса pull процедура публикации функции во многом совпадает с аналогичной процедурой в централизованном рабочем процессе. Для начала необходимо убедиться, что локальная ветка main синхронизирована с вышестоящей веткой main . Затем выполняется слияние функциональной ветки с веткой main , и обновленная ветка main помещается обратно в центральный репозиторий.

Работу с запросами pull можно упростить с помощью решений по управлению репозиториями продуктов, например Bitbucket Cloud или Bitbucket Server. Для примера можно изучить документацию Bitbucket Server по запросам pull.

Пример

Ниже приводится пример сценария, в котором используется рабочий процесс с функциональными ветками. В этом сценарии команда выполняет проверку кода в рамках запроса pull по новой функции. Это один из множества вариантов использования данной модели.

Мэри начинает разработку новой функции

Чтобы начать разработку новой функции, Мэри необходимо иметь обособленную ветку для работы. Она может запросить новую ветку с помощью следующей команды:
```
git checkout -b marys-feature main
```
Эта команда выполняет переключение на ветку marys-feature , основанную на ветке main . Флаг -b указывает Git на необходимость создания ветки, если она еще не существует. В этой ветке Мэри без ограничений редактирует, индексирует и подтверждает изменения с помощью коммитов:
```
git status
git add 
git commit
```
Мэри идет на обед

В первой половине дня Мэри добавляет к функции новые коммиты. Перед тем как пойти на обед, она решает отправить функциональную ветку в центральный репозиторий. Это удобный способ создания резервной копии, а кроме того, если бы Мэри работала совместно с другими разработчиками, это дало бы им доступ к ее первоначальным коммитам.
```
git push -u origin marys-feature
```
Эта команда отправляет ветку marys-feature в центральный репозиторий (origin), и она посредством флага -u добавляется в качестве удаленной отслеживаемой ветки. После настройки отслеживаемой ветки Мэри может вызвать для отправки функции команду git push без параметров.

Мэри завершает работу над функцией

Вернувшись с обеда, Мэри завершает разработку функции. Перед слиянием с веткой main она должна отправить запрос pull, чтобы сообщить остальным участникам команды о готовности работы. Но сначала ей необходимо отправить в центральный репозиторий свои последние коммиты:
```
git push
```
Затем Мэри с помощью графического интерфейса Git отправляет запрос pull на слияние ветки marys-feature с веткой main , о чем участники ее команды автоматически получают уведомление. Большим преимуществом запросов pull является то, что в них комментарии отображаются непосредственно рядом со связанными коммитами. Это позволяет с легкостью задавать вопросы о конкретных наборах изменений.

Билл получает запрос pull

Билл получает запрос pull и изучает ветку marys-feature. . Билл считает, что перед ее интеграцией в официальный проект необходимо внести несколько изменений, и они с Мэри обсуждают это в запросе pull.

Мэри вносит изменения

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

При необходимости Билл может извлечь ветку marys-feature в свой локальный репозиторий и работать с ней самостоятельно. Его коммиты также будут регистрироваться в запросе pull.

Мэри публикует функцию

Когда Билл готов принять запрос pull, требуется, чтобы кто-то выполнил слияние функциональной ветки со стабильной версией проекта. Это может сделать Билл или Мэри:
```
git checkout main
git pull
git pull origin marys-feature
git push
```
Часто этот процесс заканчивается коммитом слияния. Некоторые разработчики отдают предпочтение такому варианту, поскольку в этот момент происходит символическое объединение новой функции с остальной базой кода. Однако сторонники линейной истории перед слиянием могут перебазировать функциональную ветку на последний коммит ветки main , в результате чего произойдет ускоренное слияние.

В некоторых графических интерфейсах процесс принятия запроса pull автоматизирован: все необходимые команды запускаются простым нажатием кнопки «Принять». Если это не ваш случай, наверняка существует хотя бы возможность автоматического закрытия запроса pull при слиянии функциональной ветки с веткой main .

Тем временем Джон выполняет ту же самую процедуру.

Пока Мэри и Билл работают над веткой marys-feature и обсуждают ее в запросе pull, Джон делает то же самое со своей функциональной веткой. Благодаря изоляции функций в отдельных ветках пользователи могут работать автономно и при необходимости легко делиться изменениями с другими разработчиками.

Резюме

В этом документе мы рассмотрели рабочий процесс Git с функциональными ветками. Этот процесс помогает структурировать и отслеживать ветки, предназначенные для разработки бизнес-функций. Другие рабочие процессы Git, например Git-flow или рабочий процесс с форками, ориентированы на работу с репозиториями и могут использовать процесс Git с функциональными ветками для управления моделями ветвления данных. В этом документе был рассмотрен общий пример работы с кодом и вымышленный пример реализации рабочего процесса Git с функциональными ветками. Ниже приводится несколько ключевых особенностей рабочего процесса Git с функциональными ветками:
- ориентация на схемы работы с ветками;
- возможность использования другими рабочими процессами, предназначенными для работы с репозиториями;
- поддержка совместной работы с участниками команды посредством запросов pull и проверок слияния.
Использование git rebase на этапах проверки и слияния функциональной ветки создает в Git непрерывную историю слияния функций. Модель функционального ветвления — великолепный инструмент для совместной работы в командной среде.

Получите дополнительные сведения о рабочих процессах Git в подробном руководстве по рабочему процессу Gitflow.
Похожие публикации: