[Перевод - recovery mode ] GitHub Flow
Увидев в очередной раз базворд GitFlow я психанул и решил перевести описание более простой и менее проблемной схемы работы с ветками под названием GitHub Flow. Именно её имеет смысл использовать по умолчанию, переходя к какой-то другой лишь в случае непреодолимых обстоятельств.
Создайте ветвь
Пока вы работаете над одним проектом, у вас может быть куча различных реализуемх параллельно улучшений. Некоторые из них готовы к работе, а другие — нет. Ветвление позволяет вам управлять этим рабочим процессом.
При создании ветви (branch) в проекте создается среда, в которой можно опробовать новые идеи. Изменения, вносимые в отдельной ветке, не влияют на ствол (master branch). Это позволяет вам экспериментировать и фиксировать изменения безопасно, зная, что ваша ветвь никак не повлияет на другие, пока не будет действительно готова.
Ветвление — это основное понятие в git. Весь GitHub Flow основанн именно на нем и солгасно ему есть только одно правило: всё, что находится в стволе — гарантированно стабильно и готово к деплою в любой момент.Поэтому чрезвычайно важно, чтобы любая ваша новая ветвь создавалась именно от ствола. А имя ветви было быть описательным, чтобы другим было понятно над чем в ней идёт работа. Несколько примеров:
refactor-authentication,user-content-cache-key,make-retina-avatars.
Фиксируйте изменения
Создав ветвь, начинайте вносить в неё изменения. Добавляя, редактируя или удаляя файлы, не забывайте делать новые фиксации (commits) в ветви. Последовательность фиксаций образует в конечном счёте прозрачную историю работы над вашей задачей, по которой остальные смогут понять что вы делали и почему.
У каждой фиксации есть связанное сообщение, являющееся объяснением, почему было сделано то или иное изменение. Также каждая фиксация считается отдельной единицей изменения. Это позволяет откатить изменения, если обнаружилась ошибка, или если вы решите пойти в другом направлении.
Внятное описание фиксации очень важно, так как позволяет остальным разработчикам сразу понять ваши намерения и оценить насколько внесённые изменения им соответствуют. А значит обратная связь от них придёт быстрее и окажется полезней.
Откройте запрос на слияние
Запросы на слияние (pull request) инициируют обсуждение ваших коммитов. Поскольку они тесно интегрированы с базовым git-репозиторием, любой может однозначно понять, какие изменения будут внесены в ствол, если они примут ваш запрос.
Вы можете открыть запрос на слияние в любой момент процесса разработки:
- когда у вас мало или вообще нет кода, но вы хотите поделиться некоторыми скриншотами или общими идеями
- когда вы застряли и нуждаетесь в помощи или совете
- когда вы готовы к тому, чтобы кто-либо проверил вашу работу
Используя систему @упоминаний GitHub в сообщении запроса на слияние, вы можете запросить обратную связь от конкретных людей или целых команд, будь то сосед по офису или кто-то в десяти часовых поясах от вас.Запросы на слияние полезны не только в рамках одного репозитория, но и как инструмент переноса кода между форками. Просто создайте запрос на слияние ветви из одного репозитория в ветвь из другого и действуйте дальше.
Проверьте и обсудите код
После открытия запроса на слияние команда рассматривает изменения, задавая вопросы и оставляя комментарии. Возможно стиль кодирования не соответствует принятому соглашению. Возможно отсутствуют модульные тесты. А возможно все выглядит хорошо и не вызывает нареканий. Запросы предназначены фокусировки обсуждения именно на предлагаемых изменениях и группировки вместе с ними.
Конечно вы можете продолжать пополнять ветку обновлениями в свете возникшего обсуждения. Если вам указывают, что вы забыли что-то сделать или в коде есть ошибка, вы можете исправить это в своей ветке и протолкнуть (push) на сервер. GitHub покажет ваши новые фиксации и любую дополнительную обратную связь на них всё в том же унифицированном представлении запроса на слияние.
В комментариях к запросу на слияние можно использовать markdown размету, что позволяет вставлять изображения и смайлики, использовать предварительно отформатированные текстовые блоки и другое облегченное форматирование.
Проверьте в бою
После проверки запроса на слияние и прохождения тестов ветвь можно развернуть в боевом окружении, чтобы окончательно убедиться в её работоспособности. Если ветвь вызывает какие-либо проблемы, то ее можно быстро откатить, развернув вместо неё гарантированно работоспособный основной ствол. Так как ветвь ещё не была никуда влита, то всякое её влияние на другие ветви по прежнему исключено и проблемный код не сможет поломать другие ветви. так что можно продолжить работу над задачей, пока она не будет действительно готова.
Вливайте
Теперь, когда изменения были проверены в бою, пришло время влить код в основной ствол.
При слиянии в стволе создаётся фиксация со всеми изменениями из ветки. Как и любые другие фиксации, она доступна для поиска и «перемещения во времени».
Путем включения определенных ключевых слов в текст запроса на слияние, вы можете связать проблемы (issues) с кодом. При вливании ветви в ствол связанные проблемы также закрываются. Например, ввод фразы closes #32 закрывает проблему номер 32 в репозитории. Для получения более подробной информации, ознакомьтесь с соответствующей статьей.
А если частые релизы невозможны?
Если вы не практикуете непрерывную поставку (Continous Delivery), то вам может быть сложно доводить до ствола каждую ветвь по отдельности. В этом случае просто создавайте интеграционный ветви, куда вливайте лишь те ветви, что считаете готовыми. Если изменения одной из ветвей вызовут проблемы, то интеграционную ветвь всегда можно будет пересобрать заново, но уже не включая проблемную. Это позволит вам не срывать график релизов, даже если какие-либо из планируемых задач оказались не до конца готовы к запланированной дате.
В чём отличие от GitFlow?
В GitFlow у вас есть дополнительная ветвь develop куда сливаются все разрабатываемые в текущий момент ветви. develop необходимо «стабилизировать» перед релизом, что часто приводит либо к переносу релиза, либо «релизу с замечаниями».
В чём отличие от GitLab Flow?
В GitLab Flow у вас есть дополнительная ветвь pre-production куда сливаются все готовые к релизу ветви. Если релиз окажется проблемным и его потребуется откатить, то быстро пересобрать новый pre-production не получится — потребуется порой весьма проблемный «reverse merge» либо «стабилизация», как в случае GitFlow.
