Git - объединить, затем вернуться, затем снова попытаться объединить - PullRequest
0 голосов
/ 24 апреля 2020

Git иногда может быть крипти c, а документация там даже более того. Моя команда и я столкнулись с очень специфической ситуацией. Для справки, у нас есть готовый к производству основной филиал и развивающийся филиал. Наша стратегия ветвления заключается в следующем:

  • ветвь от мастера для создания ветки объекта
  • функция слияния с разработкой для интеграции и функционального тестирования
  • отправка запроса на слияние мастеру, когда функция сделана

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

Как правильно справиться с этой ситуацией.

PS - Попытка обернуть мою голову вокруг разницы между слиянием и перебазированием. Я понимаю, что слияние влечет за собой изменения кода и оставляет все остальное в такте, создавая новую историю для коммита. Однако, как работает rebase? Насколько я понимаю, он устанавливает одно ветвь в то же состояние, что и другое. Это правильно?

1 Ответ

3 голосов
/ 24 апреля 2020

Это очень хорошо объяснено в самой документации Git, под отменить ошибочное объединение . Цитируя Линуса:

Отмена обычного коммита просто эффективно отменяет то, что сделал этот коммит, и довольно проста. Но отмена фиксации слияния также отменяет data , что фиксация изменилась, но это абсолютно ничего не влияет на history , которое имело слияние.

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

Таким образом, «возврат» отменяет изменения данных, но это очень не «отмена» в том смысле, что он не отменяет влияния коммита на историю репозитория.

Итак, если вы думаете о «возврате» как о «отмене», то вы всегда будете пропускать эту часть возвратов. Да, он отменяет данные, но нет, он не отменяет историю.

Существует два варианта, чтобы получить изменения ветви "снова":

  1. Отменить возврат
  2. Перебазировать ветку без неисправного кода, эффективно создавая новую историю, то есть полностью новые коммиты, а затем объединить эту новую ветку (она не будет использовать ту же историю, поэтому при объединении она выглядит «новой») )
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...