git rebase на другой ветке

Question

с учетом следующего сценария:

• Мы разрабатываем функции для различных веток тем.
• Перед выпуском мы объединяем все ветки тем в master.Затем начинается непрерывная интеграция в этой ветви
• Кроме того, мы также вносим небольшие изменения (опечатки и т. Д.) Непосредственно в основную ветку
• Если все работает нормально, мы объединяем все изменения из мастераветвь в ветке реле.Эта ветка релиза будет отправлена ​​

Этот рабочий процесс в порядке, если в наших тестах нет ничего плохого.Но как только мы решаем не отправлять объект из мастера, у нас возникают проблемы.

Например:

• У нас есть 5 веток тем для различных функций
• Мы объединяем их все в master
• Кроме того, у нас есть 2 отдельных коммита непосредственно на мастере (мы исправили некоторые опечатки)
• Теперь мы узнаем, что 1 из 5 функцийне работает должным образом, мы не можем отправить его
• Мы все еще хотим отправить другие 4 функции (+ 2 коммита, непосредственно сделанные на мастере)

Единственный вариант, который у нас есть сейчасэто: - объединить 4 ветки тем непосредственно в релиз - вишня выбрать 2 коммита на мастере в релиз

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

Я хотел бы иметь сценарий, в котором мы можем:

• увидеть все коммиты (или лучше: объединенные ветви)
• отменить все изменениячто мы не хотимв следующем выпуске
• объединить все остальные изменения в выпуск

Я уже провел некоторые исследования и столкнулся с git rebase.git rebase --interactive подошел довольно близко к тому, что я ожидал.

Лучший сценарий будет:

• перебазировать все изменения с главного на интерактивный выпуск
• удалить все коммиты(или лучше ветки), которые мне не нужны * В выпуске 1054 *
• есть только те изменения, которые я хочу

Проблема, однако, такова:

Когда я делаю:

git checkout master
git rebase --interactive release
<changes>

В итоге я изменяю основную ветвь, а не выпускную.Добавление опции --onto release тоже не помогает.

Есть ли возможность зафиксировать результаты ребазирования в другой ветке?

Относительно Leif

Answer 1

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

В таком случае, почему бы вам git revert не выполнить коммит слияния неисправной ветви и не продолжить с остальными? Я что-то упускаю?

Answer 2

Для дальнейшего использования взгляните на Отменить ошибочное слияние , которое объясняет некоторые сценарии "отмены" слияния.Кроме того, см. Предупреждения в руководстве Git rebase Восстановление из исходной версии и в Pro Git - История перезаписи .А если вы еще этого не сделали, взгляните на рабочий процесс проекта Git и Успешная модель ветвления Git .

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

Чтобы исправить текущую ситуацию, допустим, у нас есть следующая история с двумя фиксациями фиксаций и пятью ветвями функций.Коммиты слияния:

$ git --no-pager log --oneline --decorate --all --graph
*   e202262 (HEAD, master) Merge branch 'f5'
|\  
| * d9930ca (f5) f5
* |   f9d743b Merge branch 'f4'
|\ \  
| * | eea7737 (f4) f4
| |/  
* |   c84ad9f Merge branch 'f3'
|\ \  
| * | 135c7f7 (f3) f3
| |/  
* |   65ed393 Merge branch 'f2'
|\ \  
| * | 9a9b5b6 (f2) f2
| |/  
* |   76ae0e8 Merge branch 'f1'
|\ \  
| * | 8a02982 (f1) f1
| |/  
* | ace81a9 fix 2
* | d4b32e1 fix 1
|/  
* ab6d5b0 A

Я бы сделал следующее:

1. reset master до ab6d5b0 коммита.
2. Создать release branch.
3. Добавьте коммиты fix 1 и fix 2 в ветку релиза.
4. Предполагая, что f2 является проблемной функцией, объедините f1, f3, f4 и f5 разветвляются на ветку release.
5. Во время тестирования выполните объединение пробного прогона release с master.
6. Если все хорошо,объединить release с master.

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

# Reset master to before the fix and merge commits
git checkout master
git reset --hard ab6d5b0
# Create a release branch
git checkout -b release
# Add the fix commits back
git cherry-pick d4b32e1
git cherry-pick ace81a9
# Merge feature branches
git merge f1
git merge f3
git merge f4
git merge f5
# Dry run merge
git checkout master
git merge --no-ff --no-commit release
git reset --hard HEAD
# Merge release to master
git checkout master
git merge --no-ff release

Это оставит вас со следующей историейy:

$ git --no-pager log --oneline --decorate --all --graph
*   e24c16e (HEAD, master) Merge branch 'release'
|\  
| *   d23369a (release) Merge branch 'f5' into release
| |\  
| | * d9930ca (f5) f5
| |/  
|/|   
| *   8b90602 Merge branch 'f4' into release
| |\  
| | * eea7737 (f4) f4
| |/  
|/|   
| *   926c094 Merge branch 'f3' into release
| |\  
| | * 135c7f7 (f3) f3
| |/  
|/|   
| *   e964e13 Merge branch 'f1' into release
| |\  
| | * 8a02982 (f1) f1
| |/  
|/|   
| * bb5f6f5 fix 2
| * e8ffeef fix 1
|/  
| * 9a9b5b6 (f2) f2
|/  
* ab6d5b0 A

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