https://maxkuznetsov.ru/tags/gitflow/ Простыми словами о веб-разработке Максим Кузнецов ru E2 (v3559; Aegea) Максим Кузнецов Простыми словами о веб-разработке 49 https://maxkuznetsov.ru/all/instrukciya-kak-rabotat-s-git/ Tue, 15 Jul 2025 11:15:15 +0300 Максим Кузнецов https://maxkuznetsov.ru/all/instrukciya-kak-rabotat-s-git/ <p>(Это инструкция, которую приходится копировать из проекта в проект, поэтому размещаю и в блоге.)</p> <h2>Gitflow</h2> <p>Идейно система работы с ветками берётся из Gitflow, но с упрощениями.</p> <div class="e2-text-picture"> <img src="https://maxkuznetsov.ru/pictures/gitflow.png" width="1043" height="371" alt="" /> </div> <h2>Общее</h2> <p>В нашем проекте ветка <b>develop</b> — ветка, которая содержит стабильный результат, который можно зарелизить на прод.</p> <p>Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи/задачи:</p> <ul> <li>стабильного качества (по мнению разработчика (всегда) и менеджера (аппрув менеджера требуется, если этого требует конкретная задача);</li> <li>из спринта, который в работе (то есть те задачи, которые должны быть в ближайшем релизе).</li> </ul> <p>Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop. Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).</p> <h2>Правила именования</h2> <p>Каждый коммит и пулл-реквест должны именоваться в следующем формате:</p> <blockquote> <p>[Sentry] EDS-1004: <пояснение></p> </blockquote> <p>В квадратных скобках можно указать часть системы, которая затрагивается — это упростит поиск коммита, если что-то сломается. Списка частей системы нет, выбирайте на свой вкус. Из общих советов — это должно быть что-то широкое, чтобы был понятен контекст, но не слишком широкое, чтобы не терялся смысл.</p> <p>EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.<br /> Плюс почти все таск-трекеры позволяют сконнектиться с Gitlab/Github/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.</p> <h2>Работа с ветками</h2> <ol start="1"> <li>Из ветки main (или аналогичных prod/master) создается ветка develop.</li> <li>На каждую фичу создаётся новая ветка вида feature/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера, <short-description> — краткое описание задачи на английском языке. Например: `feature/TASK-1777-change-forms-for-clients`.</li> <li>Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.</li> <li>Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.</li> <li>Для релиза ветку develop мерджим в ветку main через MR в Gitlab/Githab/etc.</li> <li>Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix/XXX-short-description.</li> <li>Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.</li> <li>После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.</li> <li>Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.</li> <li>Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать git pull, чтобы подтягивать все изменения c ветки develop. Это позволит подтягивать все изменения текущего спринта и разрешать конфликты как можно быстрее. Свою задачу можно протестировать на стейдже, залив её туда без мерджа.</li> </ol>