Стратегия ветки Git для небольшой команды разработчиков [закрыто]


186

У нас есть веб-приложение, которое мы обновляем и выпускаем почти ежедневно. Мы используем git в качестве нашей VCS, и наша текущая стратегия ветвления очень проста и неэффективна: у нас есть основная ветвь, и мы проверяем изменения, которые нам «нравятся». Это работает, но только до тех пор, пока мы не проверим критические изменения.

У кого-нибудь есть любимая стратегия Git Branch для небольших команд, которая отвечает следующим требованиям:

  1. Хорошо работает для команд от 2 до 3 разработчиков
  2. Легкий и не слишком сложный процесс
  3. Позволяет разработчикам с легкостью изолировать работу над исправлениями ошибок и более крупными функциями
  4. Позволяет нам поддерживать стабильную ветвь (для тех моментов, когда нам нужно, чтобы наши рабочие серверы работали)

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

Ответы:


247

Вы могли бы извлечь выгоду из рабочего процесса, описанного Скоттом Чаконом в Pro Git . В этом рабочем процессе, у вас есть две ветви , которые всегда существуют, мастер и развиваться .

master представляет собой наиболее стабильную версию вашего проекта, и вы только когда-либо внедряетесь в производство из этой ветви.

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

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

Скотт описывает эти длительно работающие ветви как «бункеры» кода, где код в менее стабильной ветви в конечном итоге «перейдет» к той, которая считается более стабильной после тестирования и общего одобрения вашей командой.

Шаг за шагом, ваш рабочий процесс в этой модели может выглядеть следующим образом:

  1. Вам нужно исправить ошибку.
  2. Создайте ветку с именем myfix , основанную на ветке разработки .
  3. Работайте над ошибкой в ​​этой ветке, пока она не будет исправлена.
  4. Слить myfix в разработку . Запустите тесты.
  5. Вы обнаружите, что ваше исправление конфликтует с другим исправлением ветки темы, с которым ваш коллега слился в процессе разработки, пока вы работали над исправлением.
  6. Внесите больше изменений в ветку myfix, чтобы справиться с этими конфликтами.
  7. Объедините myfix с разработкой и запустите тесты снова.
  8. Все отлично работает Слияние развивается в мастера .
  9. Развертывание в производство от мастера в любое время, потому что вы знаете, что это стабильно.

Для получения более подробной информации об этом рабочем процессе обратитесь к главе « Ветвящиеся рабочие процессы» в Pro Git.


7
Также Скотт Чакона имеет отличную статью на своем сайте о том , как рабочий процесс GitHub с Git работает - scottchacon.com/2011/08/31/github-flow.html
program247365

71
Я думаю, что это замечательно, за исключением того, что если вы создаете ветки с исправлениями ошибок из ветки разработки, вы вынуждены не можете объединить их с master и развернуть, не добавляя при этом все остальное «новое», которое вы еще не выпустили, может быть настоящей болью, если в этой ветке есть что-то, что требует документирования / изменения базы данных или что-то еще, что трудно сделать Я думаю, что для срочных "исправлений", вы должны сделать свою ветку от мастера.
Ричард

5
Что если мы разрабатываем 2 отдельные функции, F1 и F2, где F1 должен быть выпущен через неделю, а F2 должен быть выпущен через 2 недели, при условии, что развитие F1 и F2 совпадает? Есть предложения по этому поводу?
Мурат Деря Озен

4
Это developненужное «решение» проблемы, которой нет у git. Насколько я могу судить, успех связан с хорошо написанной ошибочной статьей без комментариев. Вот встречная статья barro.github.io/2016/02/…
Тим

5
На шаге 8 объединение ветви разработки с master звучит как плохая идея, учитывая, что часть кода в разработке может быть не готова к запуску в производство. Не лучше ли объединить ветвь функций с мастер?
Тодд
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.