Имеете производственный филиал или используете мастер?

Я работаю в небольшой команде с другими удаленными разработчиками над Railsприложением. Мы начинаем изменять наш gitрабочий процесс. Мы подумали о разветвленной структуре, как показано ниже:

(dev) -> (qa) -> (stag) -> (master)

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

(master) -> (qa) -> (stag) -> (prod)

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

Каковы будут некоторые недостатки использования структуры ветвления, когда master активно используется для разработки, а отдельная ветка prod - это то, что вы используете для развертываний?

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

Реальная беда вот один из процесса и процедуры. Более старшие разработчики, которые обеспокоены тем, что выполнение этого одним способом может запутать новых разработчиков, должны быть готовы потратить время, чтобы объяснить, что такое модель релиза и почему это так.

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

Я вижу твою дилемму. У меня это тоже было, пока я не узнал, что я всегда думал о мастере.

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

Из документации / книги Git - Git ветвление Git

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

Итак, если у вас есть предпочтительный рабочий процесс, и с ним сложно работать, потому что разные разработчики в команде имеют разные представления о master. Вы можете даже подумать о переименовании, masterчтобы сказать prodи использовать рабочий процесс, как показано ниже:

(dev) -> (qa) -> (stag) -> (prod)

Вот как вы меняете имя главной ветки .

Я НЕ говорю, что вы должны изменить masterназвание филиала. Но если у вас есть предпочтительный рабочий процесс, и он помогает изменить masterимя ветви, сделайте это во что бы то ни стало :-)

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

Если вам не хватает последнего, то обзоры кода помогут (часто, более дисциплинированные люди все равно захотят обзоры кода).

Вот почему мы настраиваем наше Git-репо (мы используем Gitlab), чтобы только определенные люди могли объединять запросы на извлечение, и каждый разработчик получает собственный закрытый форк основного репо.

Это решает две проблемы:

1. Новые разработчики не могут изменить неправильную ветку (поскольку они не могут перенести свою работу прямо в основной репозиторий). Они могут подтолкнуть кmaster на свое собственное репо, но это будет исправлено, когда поступит запрос на извлечение.

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

Все зависит от общего процесса разработки программного обеспечения. Управление конфигурацией и то, как появляется новая версия, невозможно определить, не зная об общем процессе.

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

Они сочли бы (master) -> (release) с организацией промежуточных шагов, возможно, 1,2.

Кроме того, существует более «классическая» фракция, которая имеет процесс, управляемый планированием и запланированными шагами интеграции в направлении этапов, где выпуск «единицы работы» - это запланированная операция с такими требованиями, как «только выпуск, когда она (единица) протестирована». и должен соответствовать следующему запланированному этапу ». Там планирование включает управление версиями «единиц работы», и обычно они идут на все, чтобы определить, как должен выглядеть следующий запланированный выпуск продукта с точки зрения функций и исправлений. Ради планирования они хотят знать, что то, что выпускает разработчик, является «правильным» и осознанным актом совершения единицы работы.

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

Таким образом, «классический» рабочий процесс будет: (dev) -> (unit) -> (интегрирование) -> (test / qa) -> (production).

Роль интегратора заключается в том, чтобы «принимать / покупать» выпущенные блоки или отклонять их, если они не соответствуют потребностям следующего следующего выпуска.

Кроме того, можно отметить, что эти 2 основных подхода можно смешать подходящими способами.

Исходя из моего опыта (который был в основном связан с использованием «классического» подхода), «классический» подход неплохо работал в проектах из примерно 4-50 человек в команде.