Git освобождает управление

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

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

    • merge release-2 для овладения и зависания, связанного с фиксацией, для release-3?
    • Функция завивки вишни, связанная с фиксацией, чтобы овладеть, а не вишней, выбрать ее для выпуска-3?
    • sth else?

  • Когда мне нужно изменить sth во всех версиях, должен ли я делать это на master и cherry-pick на всех ветвях?

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

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

Я не совсем уверен, когда я должен выбрать cherry-pick, когда мне нужно объединиться, и если поток кода между ветвями будет правильным.

ОТВЕТЫ

Ответ 1

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

Посмотрите также на gitworkflows справочной страницей.

Ответ 2

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

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

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

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

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

2/Когда мне нужно изменить sth во всех версиях, должен ли я делать это на master и cherry-pick на всех ветвях?

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

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

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

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

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

Ответ 3

Я бы сделал:

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

2) Зафиксировать r1, слить до r2, слить r2 на master и затем слить master на r3

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

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

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