Как выбрать модель рабочего процесса и ветвления Git, подходящую для вашей команды

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

Лучшая организация репозитория, более быстрая разработка

С появлением простых в использовании конвейеров автоматизации, таких как Jenkins, многие компании начинают осуществлять непрерывную интеграцию и доставку (CI/CD), при этом изменения от разработчиков часто объединяются в репозиторий, обычно поставляя продукт еженедельно, а не ежемесячный график.

Такая скорость сильно нагружает вашу организацию, особенно когда речь идет о Git. Если у вас есть 50 человек, пытающихся внести изменения в одну и ту же ветку master , у вас возникнут проблемы с частыми конфликтами слияния.

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

Особенности и развитие филиалов

Есть две большие проблемы, над решением которых работают ветки Git: синхронизация ваших внутренних команд и поддержка вашего общедоступного релиза.

Когда вы запускаете ветку в Git, новые коммиты будут делаться в этой ветке, а не в master. Это может быть полезно для отслеживания индивидуального прогресса в данной функции или исправлении ошибок; например, каждая ветвь может реализовать функцию, описанную в задаче в службе Канбан, такой как Jira, Trello или Github Issues & Projects.

Обычно слияние веток выполняется с помощью запросов на включение, функции размещенных решений Git, таких как Github, когда команда запрашивает, чтобы мастер извлекал из функции. ветку и интегрировать изменения для всех. Это может быть очень полезно для команд, выполняющих QA и модульное тестирование, чтобы убедиться, что ветвь работает должным образом, прежде чем продвигаться вверх по цепочке.

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

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

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

Магистральная разработка

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

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

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

После готовности к выпуску для каждого выпуска создается новая версионная ветка. Это отделяет выпуски от master, а также помогает добавлять или выбирать исправления для выпусков LTS.

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

Тем не менее, это не очень хорошая организация, поскольку она зависит от дисциплины и хороших разработчиков. Это действительно здорово для быстрого выпуска продуктов или быстрого повторения существующих проектов, но как только вы добавите в проект больше младших разработчиков или получите больше соавторов с открытым исходным кодом, он начнет показывать свои недостатки.

Традиционный поток Git

«Git Flow» — это рабочий процесс, который работает во многих командах. Это сложнее, чем простой рабочий процесс разработки на основе магистрали, но он дает много преимуществ для проектов с открытым исходным кодом и крупных проектов с большим количеством членов команды.

В стратегии ветвления Git Flow ветки функций живут дольше и являются основным направлением ежедневной интеграции. Команды будут работать над функциями до тех пор, пока они не будут готовы к производству, а затем пройдут процесс запроса на включение, чтобы получить их одобрение. Одновременно может быть любое количество функций, в том числе те, которые живут достаточно долго, чтобы их нужно было перебазировать на более поздние коммиты master.

С Git Flow доступ более ограничен, так как у большинства разработчиков нет разрешения на слияние напрямую с develop и, конечно же, не с master, и им придется создавать ветки по мере необходимости. основной метод внесения изменений.

Git Flow, естественно, оставляет время для надлежащей проверки кода в процессе запроса на вытягивание. Это позволяет обрабатывать конфликты с помощью PR, перебазирования и слияния, а не постоянно меняющейся ветки магистрали. Это имеет смысл для открытого исходного кода, поскольку эти ответвления могут исходить от сторонних разработчиков, но также имеет смысл в средах больших команд или для групп, разрабатывающих монолитные продукты со многими компонентами.

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

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

Такое разделение упрощает управление небольшими исправлениями ошибок, которые должны быть выпущены до того, как master будет объединен с последними выпусками. Ветка релиза работает почти так же, как и функциональная ветвь, при этом фича заключается в том, что она помечается как стабильная версия.

Конечно, постоянные пул-реквесты, перебазирование и слияние — это тяжелая работа, и она может быть утомительной, если вы пытаетесь работать быстро. Но так же, как статическая типизация или модульные тесты, в конце концов стоит поддерживать порядок и бесперебойную работу.

Выберите то, что подходит именно вам

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

Но если у вас возникли проблемы с Git, вы можете попробовать разработку на основе магистрали или Git Flow. По крайней мере, понимание организации вашего репозитория поможет вам улучшить процесс интеграции.