git rebase в многоотраслевом сценарии

Question

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

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

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

Answer 1

У нас есть 3 этапа (соответствующие филиалы)

1. Тестирование (мастер), менее чувствительная ветвь
2. Постановка (постановка), умеренно чувствительная ветвь
3. Производство (производство), Самая чувствительная отрасль
4. У нас также есть отдельные ветви для каждой реализуемой нами функции (наименее чувствительная ветвь)

Вот как мы решаем слияние с ребазом

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

Шаги:

(обновлять копию производства)

git checkout production
git pull --rebase

(всегда перебазировать ветвь объекта при производстве)

git checkout feature-branch
git pull --rebase
git rebase production

(всегда перебазировать ветку тестирования в производственной среде, ветку функций слияния для тестирования разработчиков)

git checkout master
git pull --rebase
git rebase production
git merge feature-branch

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

git checkout staging
git pull --rebase
git rebase production
git merge feature-branch

(при одобрении при принятии пользователем, включить функциональную ветвь в производство)

git checkout production
git pull --rebase
git merge feature-branch

Для этого могут быть более оптимизированные шаги.
Мы определенно с нетерпением ожидаем услышать о лучшей альтернативе.

Answer 2

Я не уверен, что правильно понял ваш вопрос, но обычно

git checkout a; git rebase c; git checkout b; git rebase c;

приведет к такому дереву:

--c----a
  +----b

, тогда как

git checkout a; git rebase c; git checkout b; git rebase a;

приведет к такому дереву:

--c----a----b

Мое предложение таково: просто попытайтесь изобразить в своей голове, как бы вы хотели, чтобы итоговое дерево выглядело, и прочитайте примеры на человеке git-rebaseстр.