Nano Hash - криптовалюты, майнинг, программирование

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

учитывая следующий сценарий:

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

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

Например:

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

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

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

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

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

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

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

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

Однако проблема в следующем:

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

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

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

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

с уважением Лейф

git integration rebase git-rebase
20.12.2011

  • Можете ли вы привести более конкретный пример? Ваш сценарий сбивает с толку. 20.12.2011
  • Я немного изменил формулировку и добавил пример, надеюсь, он более понятен. 20.12.2011
  • Разве вы не должны сделать это в обратном порядке? git chechout release git rebase -i master ... 20.12.2011
  • Я тоже пробовал это, и это привело к noop 20.12.2011

Ответы:


1

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

В таком случае, почему бы вам git revert не выполнить коммит слияния ошибочной ветки и не перейти к остальным? Есть что-то, что мне не хватает?

21.12.2011

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.
  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

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

$ 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 остается чистым, а проблемы с управлением релизом из-за проблем с выбором функций могут быть смягчены.

21.12.2011
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..