Привет, Хабр! Меня зовут Николай Пискунов — я ведущий разработчик в подразделении Big Data. И сегодня в блоге beeline cloud мы продолжим серию статей про Git и Gitflow — рассмотрим релизный цикл: то есть то, как общий код команды должен попасть в прод. Для этого в GitFlow существует процесс и ветка под названием release.
Ветки release — это временные ветки в Gitflow, которые создаются для подготовки релиза нового продукта.
Ветка release используется для следующих целей:
Подготовка к выпуску нового продукта
Создание релизной версии проекта
Тестирование и отладка кода перед выпуском
Когда вы создаете ветку release, вы создаете отдельную ветку для подготовки релиза нового продукта. Ветка release содержит изменения, которые готовы к выпуску, но еще не были официально выпущены.
Ветка release применяется для следующих типов изменений:
Фиксация ошибок
Оптимизация кода
Добавление новых функций
Gitflow рекомендует использовать ветки release для следующих целей:
Создание временной ветки для подготовки релиза нового продукта
Тестирование и отладка кода перед выпуском
Merge изменений в ветку master, чтобы они были официально выпущены
Таким образом ветка 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 и обратитесь к своему более опытному коллеге).
Область файла с конфликтом выглядит примерно так:
```
<<<<<<< HEAD
Тут содержимое файла, которое хранится в ветке слияния
=======
Тут изменения, которые приводят к конфликту
>>>>>>> feature/new-feature
```
Разобраться с конфликтами можно несколькими путями. Но здесь я рассмотрю один с использованием встроенных средств 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 и проявился на проде. Следите за новыми выпусками.