Исправление опубликованной ветви с неправильной родительской веткой

Question

Я столкнулся с проблемой, когда я опубликовал ветку в моем общедоступном репозитории git, в которой была неправильная родительская ветка. Мои попытки исправить это усугубили ситуацию.

Изначально у меня было:

  A <-- master
   \
    B <-- abstract-test-rule
     \
      C <-- run-leaf

Я отправил abstract-test-rule и run-leaf в мой общедоступный репозиторий github и сделал запросы на получение каждого из них. Затем я понял, что "run-leaf" включает коммит B; Я имел в виду разветвить «беги-лист» от «А». Итак, я запустил git revert B на ветке "run-leaf":

  A <-- master
   \
    B <-- abstract-test-rule
     \
      C--B' <-- run-leaf

Я снова отправил «run-leaf» в мой публичный репозиторий github.

Вопрос 1: Что я должен был сделать? Я предполагаю, что правильнее было бы создать новую ветвь из A только с дельтой из коммита C, перенести ее в мой публичный репозиторий github, отменить предыдущий запрос на извлечение и создать новый. Какой самый простой способ сделать это?

К сожалению, ветвь "run-leaf" была объединена с родительским репозиторием из коммита C , а затем B 'была объединена с родительским репозиторием.

Я знал, что объединение "abstract-test-rule" теперь будет болезненным для владельца родительского репозитория, поэтому я попытался подготовить "abstract-test-rule" для слияния. К этому времени мой репо выглядел так:

  A <-- master
   \
    B--D--E <-- abstract-test-rule
     \
      C--B' <-- run-leaf

Я вошел в свой репо, вытащил из родительского репо в "master", а затем слил "master" в "abstract-test-rule". Слияние было беспорядочным (потому что, я полагаю, я сливал версию B 'родительского репозитория в "abstract-test-rule"). После всего этого у нас есть очень запутанные различия .

Вопрос 2: Был ли для меня более простой способ очистить "abstract-test-rule"? Другими словами, я хотел объединить «master» в «abstract-test-rule», но избегать слияния версии B 'моего репо-репозитория в «abstract-test-rule»

Вопрос 3: Каков наилучший способ убедиться, что слияния с родительским репозиторием были выполнены правильно? Прямо сейчас я просто вытаскиваю из родительского репозитория, объединяю свою версию веток с "master" (просматривая различия из слияния) и запускаю git diff master, чтобы убедиться, что ветвь теперь идентична "master"

Спасибо!

Answer 1

Вопрос 1: Что я должен был сделать? Я предполагаю, что правильнее было бы создать новую ветвь из A только с дельтой из коммита C, перенести ее в мой публичный репозиторий github, отменить предыдущий запрос на извлечение и создать новый. Какой самый простой способ сделать это?

Это зависит от того, потянул ли кто-нибудь ваши изменения. Если никто не потянул ваши изменения, вы можете удалить ветку и создать новую с нужными коммитами. Если ваши изменения попали в другое репо, вы можете только git revert сделать нежелательный коммит. Как правило, если вы опубликовали ветку, то безопаснее всего git revert, поскольку в большинстве случаев вы не можете быть уверены, что никто не потянул нежелательную ветку.

редактировать: пересадка ревизии

Вы можете создать новую ветку только с набором изменений C либо

git checkout -b newbranch A # <- branch name or commit-id
git cherry-pick SHA1(C) # repeat for every wanted commit

или

git checkout -b newbranch run-leaf
git rebase -i HEAD~10 # large-enough number to include every commit you want
                      # to strip, and remove every unwanted commit in the editor

Оба способа создают новую ветку только с необходимыми коммитами.

Вопрос 2: Был ли для меня более простой способ очистить "abstract-test-rule"? Другими словами, я хотел объединить «master» в «abstract-test-rule», но избегать слияния версии B 'моего репо-репозитория в «abstract-test-rule»

Пока изменения не опубликованы, вы можете git rebase -i историю веток. Когда изменения опубликованы, вы не можете редактировать историю.

редактировать

Поскольку ваши изменения уже распространены, рекомендуется отменить набор изменений. Вы также могли бы удалить нежелательные изменения с помощью интерактивной перебазировки, и git push -f это изменится, но каждый другой, кто вытащил старую ветвь, вероятно, столкнется с проблемами при следующем обращении вашего репо. См. этот SO вопрос и git docs для получения дополнительной информации об этом.

Вопрос 3: Каков наилучший способ убедиться, что слияния с родительским репозиторием были выполнены правильно? Прямо сейчас я просто извлекаю из родительского репозитория, объединяю свою версию веток с "master" (просматривая diff-файлы из слияния) и запускаю git diff master, чтобы убедиться, что ветка теперь идентична "master"

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