управление релизами git

Question

Я не смог найти ничего, что является «правильным» подходом к управлению релизами с помощью git. Скажем, у меня есть ветки master, release-1, release-2 и release-3. Выпуск 1 уже выпущен, и я делаю только исправление ошибок и помечаю выпущенные версии. Выпуск 2 скоро будет выпущен, и я разрабатываю в основном в этой ветке, а в 3 я разрабатываю вещи, которые будут необходимы в будущем.

1. Когда я добавляю какую-то функцию в Release-2, она также должна перейти к 3, но не к 1, если я:

   • объединить release-2 с master и связать вишню с коммитом в release-3?
   • Вишневый пик, связанный с коммитом мастер, и чем вишневый пик для релиза-3?
   • Что еще?

2. Когда мне нужно изменить sth во всех версиях, я должен сделать это на master и выбрать его для всех веток?

3. Должен ли я обновлять мастер до последней версии (ветвь релиза 3) или, вернее, разработчика до релиза 3 и объединяться с мастером непосредственно перед тем, как мне понадобится ветка релиза 4?

4. Когда я исправляю sth на выпуске-1 или выпуске-2, я должен слить или выбрать вишню для мастеринга или скорее?

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

Answer 1

Смотрите следующие записи в блоге Junio ​​C Hamano (git keeper):

• Завершение слияния
• Никогда не сливаться обратно (о ветвях, разветвленных с намерением не сливаться обратно)
• Устранение конфликтов / зависимостей между ветками темы на раннем этапе
• Приколы с удаленными ветками (1)
• Приколы с удаленными ветками (2)

Взгляните также на страницу руководства gitworkflows .

Answer 2

То, что вы спрашиваете, это обычно рабочий процесс слияния проблема: что объединять, откуда и куда.

Но вы также должны помнить, что в DVCS на слияние также будут влиять соображения публикации (это ветви, отправленные в локальные репозитории или публичные)

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

---

1 / Когда я добавляю какую-то функцию в release-2, она также должна перейти к 3, но не к 1

Вы действительно можете объединить r2 с мастером, сделав несколько коммитов для r2 для достижения необходимых эволюций. Таким образом, в master видно только ограниченное количество коммитов, что позволяет избежать «беспорядка» коммитов.
Однако для r3 вы можете выбрать то, что вам нужно, из r2, если r3 выдвигается и публикуется. В противном случае, вы можете перебазировать r3 на r2. Смотрите " рабочий процесс git и ребаз против слияния " вопрос

2 / Когда мне нужно изменить sth во всех версиях, я должен сделать это на master и выбрать его для всех веток cherry *

Вы должны сделать это на r2, а затем объединить на master и r1 и r3. Таким образом, в эти ветви добавляется только один коммит.

3 / Должен ли я обновлять мастер до последней версии (ветка release-3) или, вернее, разработчика до релиза-3 и объединяться с мастером непосредственно перед тем, как мне понадобится ветка release-4?

Это зависит от того, что вы хотите, чтобы ваши коллеги увидели, когда они клонируют репо.
Но из 1 / я понимаю, что master представляет r2 (текущая разработка), а не r3 (будущий, долгосрочный рефакторинг)

4 / Когда я исправляю sth на выпуске-1 или выпуске-2, должен ли я объединить или выбрать вишню для мастеринга или скорее?

• r1: cherry-pick: не все, что вы исправляете на r1, предназначено для объединения с текущей разработкой.
  На самом деле, я бы предпочел более радушно выбрать r1, установленный на r2, убедиться, что все работает там, а затем влиться в master.
• r2: объединить. Если master представляет r2, достаточно простого слияния.

Answer 3

Я бы сделал:

1) Слияние r2 с мастером, а затем мастер с r3 (r3 должен быть в состоянии принять все изменения мастера)

2) Передать в r1, объединить с r2, объединить r2 с мастером, а затем объединить мастер с r3

3) Возможно, вам следует использовать master вместо r3 и разрабатывать его только на ветке r3, когда релиз находится в стадии подготовки, и объединить все изменения здесь с master (это будет следующая версия). Или используйте "master" и "next" в качестве Linux.

4) Слияние с мастером

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