Git, Gitflow и ветка release: как разместить общий код команды в прод

Привет! Меня зовут Николай Пискунов — я ведущий разработчик в подразделении Big Data. И сегодня в блоге beeline cloud поговорим про Git и Gitflow — рассмотрим релизный цикл: то есть то, как общий код команды должен попасть в прод. Для этого в GitFlow существует процесс и ветка под названием release.

Ветки release — это временные ветки в Gitflow, которые создаются для подготовки релиза нового продукта.

Ветка release используется для следующих целей:

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

Ветка release применяется для следующих типов изменений:

Gitflow рекомендует использовать ветки release для следующих целей:

Таким образом ветка release используется только для временных изменений – она не должна содержать изменения, которые могут повлиять на функциональность и безопасность проекта.

Когда вы закончите подготовку релиза, вы можете merge-ить изменения в ветку master, чтобы их выпустить официально.

Как победить конфликты в запросах на слияние

Предположим, у нас есть два готовых изменения, которые нужно разместить в прод. Они находятся в разных ветках feature и еще не включены в ветку master.

Первое, что требуется сделать, создать merge-request’ы (запросы на слияние) в ветку develop. Как создавать MRы, я рассказывал тут, только в этот раз каждый из разработчиков выбирает свою ветку в качестве начальной точки, а ветку develop в качестве целевой.

Предположим, что Иван завершил разработку быстрее Маши, создал MR, который прошел проверки и его код попал в ветку develop раньше, чем код Маши. Этот код тестировщики благополучно начали тестировать. Маша тоже заканчивает свою задачу. У нее немного больше изменений, она внесла их в файлы и классы, уже измененные Иваном.

И когда Маша начала выполнять запрос на слияние, то получила вот такое сообщение:

По сути Маша получила merge conflict или конфликт слияния — это ситуация, которая возникает в Git, когда вы пытаетесь объединить изменения из двух или более веток. Но Git не может автоматически объединить эти изменения, поскольку они конфликтуют друг с другом.

Это происходит, когда вы пытаетесь объединить изменения из двух веток, которые изменяли один и тот же файл или регион файла. Git не знает, как объединить изменения, поэтому он оставляет файл в состоянии конфликта.

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

Git предоставляет вам несколько способов разрешения конфликта слияния:

1. Manual merge: ручная обработка конфликта — это возможность вручную редактировать файлы и решать конфликты.

2. Automatic merge: автоматическое объединение — возможность Git автоматически объединять изменения, но иногда может приводить к ошибкам.

3. Resolve conflict: разрешение конфликта — это возможность Git оставить файл в состоянии конфликта, который можно решить вручную позже. (Если вы не договорились с командой о том, что оставляете файлы проекта в таком состоянии, то крайне не рекомендую так делать, поскольку это сломает ваш проект. Если вы не можете решить этот конфликт, то лучше не трогайте данный MR и обратитесь к своему более опытному коллеге).

Область файла с конфликтом выглядит примерно так:

Разобраться с конфликтами можно несколькими путями. Но здесь я рассмотрю один с использованием встроенных средств IDE Intellij IDEA.

Алгоритм решения Машиной проблемы следующий. Когда получаем конфликт слияния, вот что нужно сделать:

1. Обновить локально ту ветку, в которую вы делали запрос на слияние. В нашем случае это ветка develop.

2. Влить изменения из локально обновленной ветки develop в ветку, которая привела к конфликту. В нашем случае, это ветка feature/masha_feature.

3. После локального слияния вы получите те же самые конфликты, которые получили при создании запроса на слияние, только локально. А список конфликтов выводится в отдельном окне:

4. Для разрешения конфликтов нужно выбрать файл, который вы хотите исправить и нажать на кнопку merge. (Можно воспользоваться средствами IDE и выбрать только свои изменения или изменения, которые на данный момент находятся в ветке слияния (Accept Yours или Accept Theirs), если изменения позволяют это сделать).

В отдельном окне откроется редактор, в котором вы сможете решить конфликт.

Слева находятся ваши изменения, справа изменения в ветке слияния, в центре получившийся файл

В центр изменения можно перенести нажимая на “>>” в случае, если вы хотите перенести изменения справа или на “<<” - слева. Нажав на крестик, вы отметите изменения. Также можно вносить изменения в центр самостоятельно, руками.

В нашем случае мы переносим изменения слева, нажав на “>>”

И отменяем изменения справа нажав на крестик

Когда все конфликты решены в окне появится надпись All changes have been processed. Save changes and finish merging. Можно нажать на нее или на кнопку Apply. После чего файл будет сохранен и исчезнет из списка конфликтующих:

5. После разрешения всех конфликтов IDE сама закоммитит изменения и останется отправить данные изменения в удаленный репозиторий.

После этих манипуляций в запросе на слияние пропадет плашка с оповещением и такой запрос можно будет успешно закрыть:

После этого ветку feature/… можно удалить

Теперь, когда все изменения находятся в ветке develop, требуется создать release, о котором я писал выше. Делать это будем также через web-интерфейс.

Создавать ветку релиз будем из ветки develop, нажав на “+” напротив нее

Затем введем название релизной ветки и название релиза. Так как это наш первый релиз, пусть и название ветки будет соответствующим:

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

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