Ветвление и объединение лучших практик в Git

У нас есть команда разработчиков из 4 и недавно перешла на Git. Мы хотим изучить передовые методы работы с разветвлением и слиянием.

Мы используем облегченную версию Git Flow. У нас есть dev, промежуточная и ведущая ветвь, которые все линейны друг с другом.

промежуточное звено разветвлено от мастера
dev разветвлен с этапа

Кроме того, мы используем ветки функций и исправлений для работы над новыми функциями и исправления ошибок.

У меня есть следующие вопросы:

Должны ли мы разветвлять ветки с dev или master?
Когда ветвь функции готова, мы должны объединить ветвь функции в dev, затем объединить dev в этап или объединить ветвь функции в стадию, а затем ветвь функции в master?

Я думаю, нам нужно перейти от мастера и объединить ветвь функции, потому что в dev может быть что-то, что мы, возможно, не захотим объединиться для постановки и мастеринга.

Каково ваше мнение? Каковы наилучшие методы?

Ответ 1

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

Относительно ветвей и развертывания:

Развертка dev развертывается автоматически для проверки серверов.
Текущая ветка выпуска развертывается автоматически на промежуточных серверах.
Мастер-ветвь развертывается вручную для живых серверов с помощью мастера выпуска.

Рабочий процесс следующий:

Создайте ветвь освобождения от мастера в начале каждого выпуска/спринта, например. релиз/2015-май.
Создайте ветку dev из версии /2015-may
Работа над новой функцией, ветвь от выпуска и название ее функции / ISSUE_NUMBER.
Работайте над своей функцией.
Когда он готов к тестированию, объедините его в dev.
Если он принят, слейте его в текущую ветку выпуска.
Если это не принято, перейдите к шагу 4.
Когда релиз готов, объедините его в мастер

После того, как релиз был развернут для работы и обнаружена критическая ошибка, мы вставляем ветвь исправления от master (например, hotfix/ ISSUE_NUMBER), объединим ее снова в мастер и развертываем снова.

Ответ 2

Это всегда зависит от того, как вы хотите работать и командного соглашения. Тем не менее.

Функция начинается с ветки dev в свою ветвь. От ведущей ветки вы должны только отсылать исправления, потому что главная ветка всегда должна быть стабильной версией вашего программного обеспечения.
Когда ветвь функции завершена, она должна быть объединена в dev, а затем в какой-то момент вы должны разветкить свою следующую версию с dev (включая некоторые функции) в новую ветку release/*, которая будет объединена в master once он стабилизирован и хорошо протестирован.

На странице Atlassian вы получите очень хорошее объяснение этого рабочего процесса

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

Также иметь изоляцию и свободу для каждой новой функции, которая будет разработана в своей собственной ветке без шума от других функций. Затем, наконец, вы объедините свои функции в свою ветвь dev и оттуда в главную ветвь для следующей версии.

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

Также кажется, что этот вопрос задавался раньше

Ответ 3

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

Я хотел бы призвать вас рассмотреть Continuous Deployment (CD) с чрезвычайно простой моделью ветвления:

В настоящее время очень легко установить компакт-диск:

Используйте Travis, CodeShip, Дженкинс или аналогичная система для запуска полной сборки и набора тестов для каждой фиксации, нажимаемой на каждую ветвь вашей кодовой базы.
Настройте Travis/Codeship/Jenkins для развертывания на производство, каждый фиксатор которого пройдет мастер, который проходит тесты.
Создайте новую ветку из master для каждой новой функции.
Введите новую функцию и проверьте ее на ветке.
Объединение ветки функций в master и просмотр ее в прямом эфире.

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

Я призываю вас попробовать. Это освободит ваш разум, чтобы сосредоточиться на том, что действительно имеет значение: создать отличный продукт! Если вы мне не верите, взгляните на эту .