Рабочие процессы могут помочь упростить и автоматизировать повторяющиеся бизнес-задачи, сводя к минимуму возможность ошибок и повышая общую эффективность. - Джейми Джонсон
После многих лет жизни в одиночестве, научившись самостоятельно создавать компьютерные программы, вы наконец-то приступаете к работе в команде. Ура! Собравшись со своими товарищами по команде и разбив все задачи, которые вам нужно выполнить, вы, наконец, решаете, что лучше всего, если ваша команда будет использовать систему контроля версий для управления сотрудничеством между вами и всеми вашими товарищами по команде. Потому что, в конце концов, система контроля версий - это система, которая фиксирует изменения в файле или наборе файлов с течением времени, чтобы вы могли позже вызвать определенные версии ». (Скотт Чакон, 2016).
Некоторое время спустя вы и ваша команда решили использовать git version control, чтобы помочь вам в разработке программного обеспечения. Немного о git: Git считает свои данные скорее снимками миниатюрной файловой системы. Каждый раз, когда пользователь совершает коммит, Git делает снимок того, как все файлы выглядят в данный момент, а затем сохраняет ссылку на этот снимок. Если файлы не изменились, Git не будет сохранять эти файлы снова, они просто свяжут файлы с предыдущими идентичными файлами, которые он уже сохранил (https://git-scm.com).
Однако проблема все еще существует. У вашей команды нет рабочего процесса! Все нажимают на основную ветку, что вызывает множество конфликтов слияния и затрудняет отслеживание кодов. Вы начинаете задаваться вопросом, есть ли лучший способ управлять git-потоком вашей команды? Как и почему нужно следовать существующему git-flow? Есть ли лучшая практика?
Что ж, есть несколько предложений, это одно из них, созданное командой Винсента Дриссена в 2010 году.
Это одно из первых предложений о том, каким должен быть поток Gitlab. Он предлагает master
branch и отдельную develop
branch, а также вспомогательные ветви для функций, выпусков и исправлений. Разработка происходит в ветке develop
, переходит в ветвь выпуска и, наконец, объединяется с веткой master
.
Однако возникают две проблемы: во-первых, разработчики должны постоянно переключаться на другую ветку, поскольку Git автоматически использует ветку master
по умолчанию. Во-вторых, ветки исправления и выпуска могут вызвать излишний эффект. В настоящее время большинство организаций практикуют непрерывную доставку, что означает, что ваша ветка по умолчанию может быть развернута.
Если честно, такой поток тоже выглядит чересчур избыточным. В реальном мире разработчики обычно останавливаются только на develop
ветви. Следовательно, ветвь master
и веткаhotfix
почти не используются. Некоторые разработчики также совершают ошибки, например, объединяют изменения только в master
, а не в ветку develop
. Причина этих ошибок в том, что поток Git слишком сложен для большинства случаев использования. Например, многие проекты выпускают релизы, но не требуют исправлений.
Это некий альтернативный поток Git, который я создал, чтобы исправить некоторые из проблем, упомянутых ранее.
Как это работает?
- Сначала создайте ветвь по умолчанию
master
в вашем репозитории. Вы должны сделать его защищенным, чтобы разработчики не могли случайно отправить свою работу в основную ветку.master
ветка может быть объединена только из веткиdevelopment
. Themaster
branch содержит тег, чтобы определить, какая это версия. - Ветвь
development
извлекается из основной ветки. Эта ветка тоже защищена. Разработчики могут сливаться только в эту ветку. Однако есть 2 способа присоединиться к этой ветке:task
веток иhotfix
веток. - Существует много
task
ветвей, и это не должно быть связано с отдельными функциями. Это должно быть как задача. Например, ветвь «внешний интерфейс страницы входа» должна быть отделена от ветки «внутренняя часть страницы входа». Вы должны объединятьtask
веток сdevelopment
веткой только в том случае, если она прошла все испытания. И перед объединением не забудьте вытащить все из веткиdevelopment
. Возможно, некоторые из ваших коллег уже что-то отправили в веткуdevelopment
. - Ветви
hotfix
следует использовать только в том случае, если вашаdevelopment
ветка содержит незначительные ошибки из несколькихtask
веток. Если эти ошибки может сделать всего 1 человек, это следует сделать в веткеhotfix
.
Преимущества
- Этот поток обеспечивает чистое состояние веток в любой момент жизненного цикла проекта.
- Он определяет, как обеспечить непрерывную интеграцию и непрерывную доставку.
- Достаточно гибок по командным решениям
Недостатки
- Это может стать сложным, когда нужно поддерживать несколько версий в продакшене.
- История Git становится нечитаемой
Использованная литература: