Привет, Хабр! Меня зовут Николай Пискунов — я ведущий разработчик в подразделении Big Data. И сегодня в блоге beeline cloud мы продолжим серию статей про Git и Gitflow — рассмотрим релизный цикл: то есть то, как общий код команды должен попасть в прод. Для этого в GitFlow существует процесс и ветка под названием release.
![](https://habrastorage.org/getpro/habr/upload_files/b7d/e2e/636/b7de2e636b1fac767eb82eabcad5afbe.jpg)
Ветки release — это временные ветки в Gitflow, которые создаются для подготовки релиза нового продукта.
Ветка release используется для следующих целей:
Подготовка к выпуску нового продукта
Создание релизной версии проекта
Тестирование и отладка кода перед выпуском
Когда вы создаете ветку release, вы создаете отдельную ветку для подготовки релиза нового продукта. Ветка release содержит изменения, которые готовы к выпуску, но еще не были официально выпущены.
Ветка release применяется для следующих типов изменений:
Фиксация ошибок
Оптимизация кода
Добавление новых функций
Gitflow рекомендует использовать ветки release для следующих целей:
Создание временной ветки для подготовки релиза нового продукта
Тестирование и отладка кода перед выпуском
Merge изменений в ветку master, чтобы они были официально выпущены
Таким образом ветка release используется только для временных изменений – она не должна содержать изменения, которые могут повлиять на функциональность и безопасность проекта.
Когда вы закончите подготовку релиза, вы можете merge-ить изменения в ветку master, чтобы их выпустить официально.
Как победить конфликты в запросах на слияние
Предположим, у нас есть два готовых изменения, которые нужно разместить в прод. Они находятся в разных ветках feature и еще не включены в ветку master.
Первое, что требуется сделать, создать merge-request’ы (запросы на слияние) в ветку develop. Как создавать MRы, я рассказывал тут, только в этот раз каждый из разработчиков выбирает свою ветку в качестве начальной точки, а ветку develop в качестве целевой.
Предположим, что Иван завершил разработку быстрее Маши, создал MR, который прошел проверки и его код попал в ветку develop раньше, чем код Маши. Этот код тестировщики благополучно начали тестировать. Маша тоже заканчивает свою задачу. У нее немного больше изменений, она внесла их в файлы и классы, уже измененные Иваном.
И когда Маша начала выполнять запрос на слияние, то получила вот такое сообщение:
![](https://habrastorage.org/getpro/habr/upload_files/921/3d4/0a1/9213d40a121485f8c94423f93b19da07.png)
По сути Маша получила merge conflict или конфликт слияния — это ситуация, которая возникает в Git, когда вы пытаетесь объединить изменения из двух или более веток. Но Git не может автоматически объединить эти изменения, поскольку они конфликтуют друг с другом.
Это происходит, когда вы пытаетесь объединить изменения из двух веток, которые изменяли один и тот же файл или регион файла. Git не знает, как объединить изменения, поэтому он оставляет файл в состоянии конфликта.
Конфликты слияния могут возникнуть, когда вы пытаетесь объединить изменения из двух веток, которые изменяли один и тот же файл полностью или его части.
Git предоставляет вам несколько способов разрешения конфликта слияния:
1. Manual merge: ручная обработка конфликта — это возможность вручную редактировать файлы и решать конфликты.
2. Automatic merge: автоматическое объединение — возможность Git автоматически объединять изменения, но иногда может приводить к ошибкам.
3. Resolve conflict: разрешение конфликта — это возможность Git оставить файл в состоянии конфликта, который можно решить вручную позже. (Если вы не договорились с командой о том, что оставляете файлы проекта в таком состоянии, то крайне не рекомендую так делать, поскольку это сломает ваш проект. Если вы не можете решить этот конфликт, то лучше не трогайте данный MR и обратитесь к своему более опытному коллеге).
Область файла с конфликтом выглядит примерно так:
```
<<<<<<< HEAD
Тут содержимое файла, которое хранится в ветке слияния
=======
Тут изменения, которые приводят к конфликту
>>>>>>> feature/new-feature
```
![](https://habrastorage.org/getpro/habr/upload_files/d8f/5cb/920/d8f5cb9204fb303ca4cb29be5a21d694.png)
Разобраться с конфликтами можно несколькими путями. Но здесь я рассмотрю один с использованием встроенных средств IDE Intellij IDEA.
Алгоритм решения Машиной проблемы следующий. Когда получаем конфликт слияния, вот что нужно сделать:
1. Обновить локально ту ветку, в которую вы делали запрос на слияние. В нашем случае это ветка develop.
![](https://habrastorage.org/getpro/habr/upload_files/eee/94c/c6c/eee94cc6ce68bfd9505240556d7f3ecc.png)
2. Влить изменения из локально обновленной ветки develop в ветку, которая привела к конфликту. В нашем случае, это ветка feature/masha_feature.
![](https://habrastorage.org/getpro/habr/upload_files/e32/f8f/e9e/e32f8fe9e24940c8e29c0c7197dc2b5e.png)
3. После локального слияния вы получите те же самые конфликты, которые получили при создании запроса на слияние, только локально. А список конфликтов выводится в отдельном окне:
![](https://habrastorage.org/getpro/habr/upload_files/17c/735/e49/17c735e49ec39e5547fded8545001742.png)
4. Для разрешения конфликтов нужно выбрать файл, который вы хотите исправить и нажать на кнопку merge. (Можно воспользоваться средствами IDE и выбрать только свои изменения или изменения, которые на данный момент находятся в ветке слияния (Accept Yours или Accept Theirs), если изменения позволяют это сделать).
![](https://habrastorage.org/getpro/habr/upload_files/4e9/e87/e01/4e9e87e0104d8919bfbd59028da86aff.png)
В отдельном окне откроется редактор, в котором вы сможете решить конфликт.
![](https://habrastorage.org/getpro/habr/upload_files/408/225/be6/408225be67e96d6b9f14d3225b86bdb0.png)
Слева находятся ваши изменения, справа изменения в ветке слияния, в центре получившийся файл
В центр изменения можно перенести нажимая на “>>” в случае, если вы хотите перенести изменения справа или на “<<” - слева. Нажав на крестик, вы отметите изменения. Также можно вносить изменения в центр самостоятельно, руками.
В нашем случае мы переносим изменения слева, нажав на “>>”
![](https://habrastorage.org/getpro/habr/upload_files/d7b/9e3/980/d7b9e3980c2f88cc2044d8351c0e5f85.png)
И отменяем изменения справа нажав на крестик
![](https://habrastorage.org/getpro/habr/upload_files/44b/735/edd/44b735eddd2386abdf0f25b8bbf4acb0.png)
Когда все конфликты решены в окне появится надпись All changes have been processed. Save changes and finish merging. Можно нажать на нее или на кнопку Apply. После чего файл будет сохранен и исчезнет из списка конфликтующих:
![](https://habrastorage.org/getpro/habr/upload_files/2c2/78c/1fe/2c278c1fe1c332e98cdcc624728153c8.png)
5. После разрешения всех конфликтов IDE сама закоммитит изменения и останется отправить данные изменения в удаленный репозиторий.
![](https://habrastorage.org/getpro/habr/upload_files/55d/ec7/074/55dec707465877580b42c094148e6c2a.png)
После этих манипуляций в запросе на слияние пропадет плашка с оповещением и такой запрос можно будет успешно закрыть:
![](https://habrastorage.org/getpro/habr/upload_files/62d/bf9/ba9/62dbf9ba9795f8bd56ac63cf61eca22b.png)
После этого ветку feature/… можно удалить
![](https://habrastorage.org/getpro/habr/upload_files/6db/e7e/856/6dbe7e856d858adf806afe4e8a91c575.png)
Теперь, когда все изменения находятся в ветке develop, требуется создать release, о котором я писал выше. Делать это будем также через web-интерфейс.
Создавать ветку релиз будем из ветки develop, нажав на “+” напротив нее
![](https://habrastorage.org/getpro/habr/upload_files/160/c9e/5b5/160c9e5b5c678b970c96933d32598a7f.png)
Затем введем название релизной ветки и название релиза. Так как это наш первый релиз, пусть и название ветки будет соответствующим:
![](https://habrastorage.org/getpro/habr/upload_files/02e/36e/cef/02e36ecef06489d88d22f20c00bf27b4.png)
Обычно тестировщики раскатывают релизную ветку на тестовых серверах и проводят тестирование этой ветки, после чего мы можем создавать запрос на слияние в ветку мастер и выкатывать приложение на прод-сервер. В итоге код всех членов команды у нас попадает в production.
На этом всё. В следующей заключительной статье я расскажу, что делать, если баг все же проскочил в ветку master и проявился на проде. Следите за новыми выпусками.