Альтернативы git-flow для управления частыми выпусками

Мне интересно, какие стратегии ветвления / выпуска git используют люди и рекомендовали бы для проекта со следующими требованиями:

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

мы пробовали использовать процесс git-flow (http://nvie.com/posts/a-successful-git-branching-model/) но было две основные проблемы с ним:

  1. код, который мы тестируем в любой момент во время ветви выпуска не совсем то же самое, что будет выпущено (с момента выпуска филиал должен быть объединен с master в конце)
  2. изменения рефакторинга трудно справиться и часто приводит к конфликтам слияния, когда ветвь выпуска сливается с master.

есть ли другие рабочие процессы git, которые подходят для этой ситуации или как другие преодолевают эти проблемы с ЖКТ-поток?

6
git

2 ответов

код, который мы тестируем в любой момент во время ветви выпуска, не совсем совпадает с тем, что будет выпущено (так как ветвь выпуска должна быть объединена с master в конце)

Это не имеет смысла. Слияние между ветвью выпуска и главной ветвью по существу должно быть только быстрым-ваша главная ветвь должна диктоваться вашими выпусками, а не наоборот.

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

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

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

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

однако при слиянии ветви выпуска в master или разработке возникают проблемы слияния в ветвь выпуска указывает на неправильное следование связанному потоку.

8

Что касается альтернатив,

Поток GitHub

GitHub Flow-это легкий, основанный на филиалах рабочий процесс, который поддерживает группы и проекты, в которых развертывание осуществляется регулярно.

  • все в главной ветви развертывается
  • чтобы работать над новой функцией, создайте дескриптивно названную ветвь master
  • когда вам нужна обратная связь или помощь, или вы думаете, что филиал готов для слияния создайте запрос pull
  • после того, как кто-то другой подписал на функцию, вы можете объединить его в master
  • как только он будет объединен и нажат на master, вы можете и должны развернуть
3