Исправление конфликтов слияния с помощью Git Rebase и экспорта - PullRequest
0 голосов
/ 07 июня 2018

Я столкнулся с несколькими конфликтами слияния с git rebase.

Мой вопрос: если я исправлю конфликты, сделаю ли я тогда что-то вроде этого:

git add files
git commit "fixed merge conflicts"

, затем продолжу с

git rebase --continue

Другой вопрос, еслиЯ запутался, могу ли я сделать

git rebase --abort 

и удалит ли это все коммиты?

Ответы [ 2 ]

0 голосов
/ 07 июня 2018

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

Перебазировать насвоего рода фундаментальный уровень, работает путем копирования (потому что коммиты никогда не могут быть изменены - это включает их обратные ссылки).Имена ветвей просто указывают на какой-то конкретный коммит.Если мы рисуем коммиты как узлы на графике, то, что мы имеем, выглядит следующим образом:

...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch

Если вы запустите git checkout your-branch && git rebase origin/whatever, Git должен copy commit J, повернувон входит в набор изменений по сравнению с его родителем G и применяет эти изменения к фиксации I (где origin/whatever указывает).Скопировав J в J', он пытается скопировать K в новый коммит K' и так далее.Возможный результат, после того, как вы разрешите все конфликты, но до того, как Git «очистит имя» от коммита L, будет:

                J'-K'-L'  <-- HEAD
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch

Самым последним шагом git rebase является удаление имени your-branchоткуда он вставлен прямо сейчас, указывая на фиксацию L, и вместо этого укажите L' - последнюю копию, сделанную ребазом:

                J'-K'-L'  <-- your-branch (HEAD)
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   [abandoned]

Если вы используете git rebase --abort вместопродолжая, Git просто отказывается от скопированной цепочки вместо этого, оставляя имя your-branch, все еще указывая на L:

                J'-K'-L'  [abandoned]
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch (HEAD)

Перед тем, как начать перебазирование, или в любое время в середине перебазирования, когда your-branch по-прежнему указывает на фиксацию L, вы можете добавить новое имя, чтобы запомнить необработанный хэш-идентификатор фиксации L:

                J'-K'  <-- HEAD
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch, extra-name

, что вы можете сделать, например, с git branch extra-name your-branch.Таким образом, после того, как вы закончите ребазинг, предполагая, что вы его закончите, вы получите:

                J'-K'-L'  <-- your-branch (HEAD)
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- extra-name

У вас нет сделать это, потому что тайно, git rebaseустанавливает специальное имя, ORIG_HEAD, чтобы запомнить, где было название вашей ветви, прежде чем оно выдернуло его из L и вставило в L'.Но имя ORIG_HEAD будет перезаписано любой другой командой Git, которую вы используете позже (может быть, другой перебаз), которая вызывает метку, подобную этой, так что это своего рода кратковременный пробел, который вы можете использовать для восстановления, если вы неt, как результат.

Ваш Git также записывает в нечто, называемое reflog для ветви, предыдущее значение имени ветви, то есть тот факт, что your-branch использовался для указаниясовершить L вместо L'.Эти записи reflog сохраняются в течение 30 или 90 дней. 1 Они не самые простые в использовании вещи, хотя:

git reflog your-branch

выплеснет все из них, но вы получитеоднострочная сводка, которую вы использовали в каждом коммите, и когда вы используете git rebase, вы обычно копируете исходную однострочную сводку из коммита L для коммита L', поэтому трудно определить, какой из них какой.

Тем не менее, некоторая комбинация ORIG_HEAD и reflogs обычно позволяет вам восстановиться без дополнительного имени.Используйте дополнительное имя, если вам удобнее.Я делаю это много: если я работаю с feature/X и мне нужно выполнить перебазирование, я создаю feature/X.0, а затем перезагружаю.Моя оригинальная серия коммитов теперь доступна как точка-ноль.Через несколько дней, если мне нужно сделать еще одну перебазку, я создаю feature/X.1, а затем перебазируюТаким образом, feature/X является самым последним, а feature/X.<number> - старшим, с более старшими, оставшимися до тех пор, пока я сам не соберу их и не выброшу.


1 Техническите, которые истекают через 30 дней, используют время expireUnreachable: это коммиты, которые не достижимы от текущего значения ссылки.Как правило, Rebase делает такой тип ссылки, поэтому по умолчанию следует сконцентрироваться на 30-дневном сроке действия.

(Записи в журнале, которые достижимы , получают значение по умолчанию 90 дней.)

0 голосов
/ 07 июня 2018

git rebase --abort просто полностью выйдет из ребаз, по существу вернув ваш репозиторий к моменту времени, прямо перед тем, как вы запустите rebase.Единственными потерянными коммитами будут совершенно новые коммиты, созданные git rebase (поскольку git rebase воспроизводит ваших оригинальных коммитов, тем самым формируя новые коммиты).

Оригинальные коммитыникогда не трогал, независимо от того, прерываете ли вы или нет.

...