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

16

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

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

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

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

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

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


источник
По моему опыту, полезно иметь одно место, где люди могут выполнять свои обязательства по своему желанию (будь то ежедневная регистрация или что-то в этом роде) - без требований «всегда компилировать». Без этого люди откладывают регистрацию и рискуют потерять код при авариях (например, сбой диска). Затем они должны распространить значимую версию оттуда и «выпустить ее» в поток интеграции. Поэтому мой предпочтительный набор этапов выглядит как (dev) -> (unit) -> (интеграция) -> (test) -> (production)
BitTickler
2
Мы успешно используем рабочий процесс git, описанный на этом сайте, с некоторыми отличиями. nvie.com/posts/a-successful-git-branching-model Единственное отличие состоит в том, что мы предпочитаем локальное сжатие ветвлений для разработки, чтобы поддерживать чистую историю и следовать логике «один коммит, одна проблема»
Jepessen
Что обычно происходит на вашей ветке?
simgineer
рекомендую для более четкого CI / CD. Основная ветвь не используется, так как она может быть неправильно истолкована. {разработка} - {блок} - {интеграция} - {подготовка} - {производство}. в синем / зеленом цвете с непрерывным наращиванием производства> активным срезом и постановкой> неактивным срезом. HEAD> развить ветку, где функции разветвляются. разработать вебхуки для запуска сборок в направлении перехода юнита к интеграции и организации (с соответствующими тегами при прохождении интеграции). Исправления в сторону разработки + производства (редко, но бывает). больше тонкостей, но общая идея.
Джимми М.Г. Лим

Ответы:

16

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

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

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

Makoto
источник
1
Я действительно думаю, что вы попали в хорошую точку. Спасибо за ответ.
+1 для пометки коммитов. Я работаю самостоятельно большую часть времени, но я отмечаю релизы по двум причинам. 1) Он отлично работает с инструментами визуальной истории Git, чтобы показать, какие коммиты действительно были в производстве. 2) Он отлично работает с такими инструментами, как GitHub, которые могут упаковывать релизные версии, проверяя отмеченный коммит и упаковывая его в zip-файл для использования.
nbering
9

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

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

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

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

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

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

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

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

Сумит Парик
источник
Это очень хороший момент. Спасибо за это. Я не знаю, зайдем ли мы так далеко, чтобы переименовать, но приятно знать, что git не относится к мастеру каким-либо особым образом. Благодарность!
6

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

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

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

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

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

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

Аарон Дигулла
источник
1

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

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

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

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

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

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

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

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

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

BitTickler
источник