Кто такие «они» и «мы» в «git revert»?

Когда возникает конфликт, во всех ситуациях применяется правило:

• ours/us — это состояние текущего HEAD (активный коммит)
• theirs/them — это состояние другой стороны (слияние фиксации, выборка/перебазирование фиксации или, в вашем случае, обратная фиксация, которую вы хотите отменить)

Некоторые дополнительные разъяснения в случае rebase (отвечая на комментарий @GabrielStaples):

если вы находитесь на my/branch и запускаете git rebase other/branch, git проверит главный коммит other/branch и начнет воспроизводить некоторые коммиты сверху.

Если возникает конфликт, поскольку проверенный коммит исходит от other/branch, ours будет приблизительно представлять other/branch, а theirs будет my/branch.

Эта часть противоречит интуиции ours должно быть моими изменениями, но она соответствует приведенному выше описанию: на момент конфликта проверенный коммит — ours, другая сторона (воспроизводимый коммит) — theirs.

Хотя на это уже довольно хорошо ответили, есть еще один способ взглянуть на все это. Так на это смотрит сам Git. Все четыре операции — выбор вишни, слияние, перебазирование и возврат — используют один и тот же механизм, а флаги --ours и --theirs для git checkout, а также расширенные параметры -X ours и -X theirs в конечном итоге ссылаются на одни и те же вещи, используя одни и те же внутренние код. Мне нравится называть этот механизм слиянием как глаголом, потому что сначала мы знакомимся с ним через git merge, когда слияние должно выполнять настоящее слияние.

Случай слияния

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

          I--J   <-- ourbranch (HEAD)
         /
...--G--H
         \
          K--L   <-- theirbranch

Здесь имя ourbranch выбирает фиксацию J, которая является нашей фиксацией в нашей ветке (в данном случае это одна из двух таких фиксаций, хотя количество фиксаций исключительно в нашей собственной ветке должно быть не менее 1, чтобы вызвать настоящее слияние). Имя theirbranch выбирает фиксацию L, которая является их фиксацией в их ветке (опять же, одна из двух, причем здесь необходима по крайней мере одна фиксация).

Что Git делает, чтобы выполнить это слияние — объединить как глагол некоторый набор файлов — для каждого файла во всех трех коммитах H, J и L сравнивает файл в H с этим в J, чтобы увидеть, что мы изменили, и сравнить файл в H с файлом в L, чтобы узнать, что они изменили. Затем Git объединяет эти два набора изменений, применяя объединенные изменения ко всему, что находится в H.

Коммит H — это база слияния коммит, коммит J — наш коммит, а коммит L — их коммит. Любое различие, будь то новый файл, добавленный нами, или файл, удаленный ими, или что-то еще, относится к коммиту H.

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

1. Настраивать:

   • read merge base commit (H) into index at slot 1
   • прочитать ours коммит (HEAD = J) в индекс в слоте 2
   • прочитать theirs commit (L) в индекс в слоте 3

2. Определите одинаковые файлы. Обратите внимание, что шаги 2 и 3 повторяются для каждого файла.

   • if there's a file named F in all three slots, it's the same file
   • в противном случае, если в слоте 1 есть что-то, попробуйте угадать переименования, которые свяжут базовый файл слияния в слоте 1 с нашим или их файлом с другим именем, который находится в слоте 2 и/или слоте 3; если не удается найти файл для переименования, наша и/или их сторона удалила этот файл; эти случаи также могут привести к конфликту высокого уровня, такому как переименование/изменение или переименование/удаление, когда мы объявляем конфликт и продолжаем, не выполняя шаг 3.
   • в противном случае (ничего в слоте 1, но что-то в слотах 2 и 3) мы имеем конфликт добавления/добавления: объявить этот конкретный файл конфликтующим и двигаться дальше, не выполняя шаг 3

3. Замкните легкие случаи и сделайте сложные случаи с помощью низкоуровневого слияния:

   • if the blob hash IDs in slots 1, 2, and 3 all match, all three copies are the same; use any of them
   • если хеш-идентификатор большого двоичного объекта в слоте 1 совпадает с идентификатором в слоте 2 или 3, значит, кто-то не изменил файл, а кто-то изменил; использовать измененный файл, т. е. взять файл, который отличается
   • otherwise, all three slots differ: do a changed-block-of-lines by changed-block, low-level merge
     • if there's a merge conflict during the low level merge, -X ours or -X theirs means "resolve the conflict using ours/theirs" where ours is whatever is in slot 2 and theirs is whatever is in slot 3
     • обратите внимание, что это означает, что везде, где нет конфликта, например, только одна сторона изменила строку 42, расширенный вариант -X вообще не применяется, и мы принимаем изменение, независимо от того, является оно нашим или их

В конце этого процесса любой полностью разрешенный файл перемещается обратно в его обычное положение нулевого слота, при этом записи слотов 1, 2 и 3 удаляются. Любой неразрешенный файл остается со всеми тремя занятыми индексными слотами (в конфликтах удаления и добавления/добавления некоторые слоты пусты, но используется какой-то слот с ненулевым номером стадии, что помечает файл как конфликтующий ).

Следовательно, объединить или объединить как глагол работает в индексе Git.

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

В конечном итоге это всегда сводится к одному и тому же уравнению: 1 = база слияния, 2 = наша, 3 = их. Это верно, даже если команда, которая загружает индекс, не git merge.

Вишневый выбор и возврат используют механизм слияния

Когда мы запускаем git cherry-pick, у нас есть график коммитов, который выглядит так:

...--P--C--...
   \
    ...--H   <-- somebranch (HEAD)

Буквы P и C здесь обозначают любую пару коммитов родитель-потомок. C может даже быть фиксацией слияния, если мы используем параметр -m для указания какого родителя использовать. (Нет никаких реальных ограничений на то, где три коммита живут на графике: я нарисовал его с H дочерним элементом некоторого коммита, который идет до P, но он может быть после пары P-C, как в ...-E-P-C-F-G-H, например, или может быть не должно быть никакой связи между коммитами P-C и H, если у вас есть несколько непересекающихся подграфов.)

Когда мы запускаем:

git cherry-pick <hash-of-C>

Git сам найдет коммит P, используя родительскую ссылку от C до P. P теперь действует как база слияния и считывается в индексный слот 1. C действует как --theirs коммит и считывается в индексный слот 3. Наш текущий коммит H является --ours коммитом и считывается во второй слот индекса. механизм работает сейчас, поэтому наша фиксация — HEAD, а их фиксация — C, с базой слияния, которая появляется, если мы устанавливаем merge.conflictStyle на diff3 или если мы используем git mergetool для запуска инструмента слияния, — это фиксация P.

Когда мы запускаем:

git revert <hash-of-C>

происходит то же самое, за исключением того, что на этот раз коммит C — это база слияния в слоте 1, а коммит P — это коммит --theirs в слоте 3. Коммит --ours в слоте 2, как обычно, из HEAD.

Обратите внимание, что если вы используете вишневый выбор или возврат к ряду коммитов:

git cherry-pick stop..start

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

...--C--D--E--...
 \
  H   <-- HEAD

git cherry-pick C..E сначала копирует D, затем E, но git revert C..E сначала возвращает E, а затем D. (Коммит C не играет роли, поскольку синтаксис с двумя точками исключает фиксации, достижимые с левой стороны выражения с двумя точками. См. документацию gitrevisions для получения дополнительной информации.)

Rebase - это повторный выбор вишни

Команда rebase работает путем повторного запуска git cherry-pick, после использования git checkout --detach или git switch --detach для перехода в режим отсоединенного HEAD. (Технически теперь это делается только внутри; в старые времена некоторые версии git rebase, основанные на сценариях оболочки, действительно использовали git checkout, хотя и с хэш-идентификатором, который все равно всегда переходил в отсоединенный режим.)

Когда мы запускаем git rebase, мы начинаем примерно так:

       C--D--E   <-- ourbranch (HEAD)
      /
...--B--F--G--H   <-- theirbranch

Мы бежим:

git checkout ourbranch   # if needed - the above says we already did that
git rebase theirbranch   # or, git rebase --onto <target> <upstream>

Первое — ну, второе — что это делает, это входит в режим отсоединения HEAD, при этом фиксация HEAD является фиксацией, которую мы выбрали с нашим аргументом --onto. Если бы мы не использовали отдельный флаг и аргумент --onto, --onto брался бы из одного аргумента, который мы указали, в данном случае theirbranch. Если мы не использовали отдельный аргумент upstream, указанный нами аргумент — в данном случае theirbranch — используется для обеих целей.

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

git rev-list --topo-order --reverse <hash-of-upstream>..HEAD

в данном случае это хэш-идентификаторы коммитов C, D и E: три коммита, которые доступны из ourbranch, но недоступны из theirbranch.

После того, как git rebase сгенерировал этот список и перешел в режим detached-HEAD, то, что мы имеем сейчас, выглядит так:

       C--D--E   <-- ourbranch
      /
...--B--F--G--H   <-- theirbranch, HEAD

Теперь Git запускает один файл git cherry-pick. Его аргументом является хэш-идентификатор коммита C, первого коммита, который нужно скопировать. Если мы посмотрим выше на то, как работает выбор вишни, мы увидим, что это операция слияния как глагола, при этом база слияния является родителем C, то есть фиксация B, текущая фиксация или --ours фиксация H, и фиксация, подлежащая копированию или --theirs, является фиксацией C. Вот почему наши и их кажутся противоположными.

Однако, как только эта операция выбора вишни завершена, мы теперь имеем:

       C--D--E   <-- ourbranch
      /
...--B--F--G--H   <-- theirbranch
               \
                C'  <-- HEAD

Теперь Git копирует коммит D с git cherry-pick. Базой слияния теперь является фиксация C, фиксация --ours — фиксация C', а фиксация --theirs — D. Это означает, что и наши, и их коммиты являются нашими, но на этот раз наш коммит — это тот, который мы только что создали несколько секунд (или миллисекунд) назад!

Он основан на существующей фиксации H, которая принадлежит им, но это фиксация C', которая принадлежит нам. Если мы получаем какие-либо конфликты слияния, они, несомненно, являются результатом того, что они основаны на H, возможно, включая какое-то разрешение конфликтов, которое мы выполнили вручную, чтобы создать C'. Но в буквальном смысле все три входных коммита наши. Слот индекса № 1 — из фиксации C, слот индекса № 2 — из фиксации C', а слот индекса № 3 — из фиксации D.

Как только мы все это сделали, наша картина теперь:

       C--D--E   <-- ourbranch
      /
...--B--F--G--H   <-- theirbranch
               \
                C'-D'  <-- HEAD

Теперь Git запускает git cherry-pick на хеше коммита E. База слияния — это коммит D, а наши и их коммиты — D' и E соответственно. Итак, еще раз, во время перебазирования все три коммита наши, хотя конфликты слияния, вероятно, являются результатом построения на H.

Когда последний выбор сделан, Git завершает перебазирование, беря имя ourbranch из старого коммита E и вставляя его в новый коммит E':

       C--D--E   [abandoned]
      /
...--B--F--G--H   <-- theirbranch
               \
                C'-D'-E'  <-- ourbranch (HEAD)

Теперь мы вернулись к обычному режиму работы с прикрепленной головкой, и поскольку git log начинается с того места, где мы находимся сейчас — с момента фиксации E' — и работает в обратном направлении, что никогда не посещает исходную фиксацию C, кажется, что мы каким-то образом изменили исходные три совершает. У нас нет: они до сих пор там, в нашем репозитории, доступны через специальную псевдо-рефу ORIG_HEAD и доступны через наши рефлоги. Мы можем вернуть их по крайней мере на 30 дней по умолчанию, после чего git gc сможет их пожинать, а затем они действительно исчезнут. (Ну, пока мы не git push переместили их в какой-нибудь другой репозиторий Git, где они все еще хранятся.)

TLDR;

Перейти к самому низу для результатов и выводов.

Подробности:

Касательно:

Затем git status показывает следующие конфликты:

deleted by them: path/to/file1.h
both modified:   path/to/file2.h
deleted by them: path/to/file1.cpp
deleted by them: path/to/test_file1.cpp
added by us:     path/to/file3.h
deleted by them: path/to/file4.h
added by us:     path/to/file5.h

Я провел несколько экспериментов и заметил следующее.

Во-первых, я вручную разрешил только конфликты в оба измененных файлах, path/to/file2.h, как обычно для любого конфликта перебазирования или слияния. Затем я добавил все файлы и завершил восстановление:

git add -A
git revert --continue

Далее я заметил, что все файлы с пометкой удалены ими, а также все файлы с пометкой добавлены нами, присутствовали / существует в моей файловой системе. Таким образом, возврат не удалил ни один из них. Далее я хотел узнать: какой коммит создал эти файлы? Чтобы увидеть это, выполните следующее (источник):

git log --diff-filter=A -- path/to/file

Это показывает git log commit_hash только для одного единственного commit_hash, который создал этот файл. Я сделал это по одному для каждого файла, который был удален ими или добавлен нами:

git log --diff-filter=A -- path/to/file1.h        # added by the commit I reverted
git log --diff-filter=A -- path/to/file1.cpp      # added by the commit I reverted
git log --diff-filter=A -- path/to/test_file1.cpp # added by the commit I reverted
git log --diff-filter=A -- path/to/file3.h        # added by a later commit
git log --diff-filter=A -- path/to/file4.h        # added by the commit I reverted
git log --diff-filter=A -- path/to/file5.h        # added by a later commit

Я обнаружил, что 4 файла, как указано выше, были добавлены фиксацией, которую я отменил. Обратите внимание, это означает, что они были добавлены самим коммитом some_commit_hash, а НЕ коммитом возврата, который был создан при запуске git revert some_commit_hash. Итак, почему они все еще существовали, если я отменил этот коммит? Что ж, оказывается, более поздняя фиксация, которую мы назовем later_commit_hash, которая произошла ПОСЛЕ some_commit_hash, затронула все 6 этих файлов, изменив 4 из них и создав 2 из них.

Давайте сгруппируем вышеуказанные файлы по группам удаленные ими и добавленные нами:

# deleted by them:
path/to/file1.h
path/to/file1.cpp
path/to/test_file1.cpp
path/to/file4.h

# added by us:
path/to/file3.h
path/to/file5.h

Теперь укажите, какой файл каким коммитом был добавлен:

# deleted by them / added by the commit I reverted (`some_commit_hash`)
path/to/file1.h
path/to/file1.cpp
path/to/test_file1.cpp
path/to/file4.h

# added by us / added by a later commit (`later_commit_hash`)
path/to/file3.h
path/to/file5.h

Итак, вы можете видеть, что удаленные ими файлы были добавлены фиксацией, которую я отменил, а это означает, что отмена этой фиксации удалит эти файлы! Таким образом, them относится к отменяемому коммиту, some_commit_hash, а us относится к оставшимся коммитам в HEAD.

Конфликт был в том, что later_commit_hash коснулся тех 4-х удаленных им файлов, поэтому git revert some_commit_hash не смог их удалить. И 2 добавленных нами файла НЕ существовали до some_commit_hash, поэтому конфликт был в том, что они не должны были существовать после реверта, но они существовали, потому что были созданы later_commit_hash.

Решение, которое я сделал, это вручную удалить все эти 6 файлов:

rm path/to/file1.h
rm path/to/file1.cpp
rm path/to/test_file1.cpp
rm path/to/file3.h
rm path/to/file4.h
rm path/to/file5.h

затем я зафиксировал это изменение как новый коммит:

git add -A
git commit

Однако вместо этого я мог бы вернуться к местоположению, предшествовавшему возврату коммита, и сначала отменить later_commit_hash, а затем отменить some_commit_hash секунду, эффективно откатив эти изменения по порядку, например так:

git reset --hard HEAD~  # WARNING! DESTRUCTIVE COMMAND! BE CAREFUL.
git revert later_commit_hash
git revert some_commit_hash
# should result in no conflicts during both of those reverts now

Результаты и выводы:

В любом случае, чтобы ответить на мой собственный вопрос:

Во время git revert some_commit_hash:

1. нас = проверенный в данный момент коммит (то есть: HEAD) на момент ввода и запуска git revert some_commit_hash, и:
2. them = (обратный или противоположный?) коммит, который вы отменяете; то есть: это некоторая эфемерная фиксация, противоположная some_commit_hash, чтобы отменить изменения some_commit_hash, предполагая, что вы запускаете команду git revert some_commit_hash.

Обновление от 7 января 2020 г.: да, похоже, это действительно так. Вот мой комментарий, который я только что оставил под другим ответом здесь. Мой комментарий, кажется, полностью коррелирует с приведенным выше наблюдением:

Ключевым выводом для меня здесь относительно git revert является, я думаю, что если у вас есть линейное дерево ...A--B--C--D(HEAD), где D является вашим текущим HEAD, и вы делаете git revert B, то B, тот самый коммит, который вы пытаетесь вернуть, становится текущим merge-base, или Слот 1 в этом слиянии, Слот 2 или наш становится D/HEAD, а Слот 3 или их становится A, или родительский коммит возвращается, правильно? Затем выполняется низкоуровневое слияние, в результате которого применяются все изменения из B..D, а также все изменения из B..A, тем самым возвращая B, верно? Это трудно.

Итак, это означает, что эта эфемерная фиксация, противоположная some_commit_hash, на самом деле является просто обратным diff или diff в направлении from some_commit_hash, вы возвращаетесь к его родительскому коммиту. . Теперь у вас под капотом происходит низкоуровневое слияние git, где база слияния — some_commit_hash для возврата, наш/нас — HEAD, а их/их — родитель some_commit_hash, также известный как some_commit_hash~. Когда git выполняет это низкоуровневое слияние, разница между some_commit_hash и HEAD (то есть: эквивалент git diff some_commit_hash..HEAD) фиксирует весь ваш новый контент, а разница между some_commit_hash и его родителем (то есть: эквивалент git diff some_commit_hash..some_commit_hash~) захватывает отменить изменения, сделанные коммитом some_commit_hash, тем самым отменив этот коммит!

Если я все правильно понял, теперь все имеет смысл!

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

Я также только что добавил сюда ответ, чтобы разъяснить нам и им для всех 4 операций git, о которых я могу думать, где это может произойти: git merge, git cherry-pick, git rebase и git revert: Кто мы и кто они согласно Git?

Нужно взглянуть на: http://ezconflict.com/en/conflictsse12.html#x53-890001.7

Ну... revert очень особенная ситуация. Итак, подумайте об обычном слиянии, с общим предком и всем остальным, целым пакетом, верно? Теперь все работает так же, как слияние, за исключением (и это большое исключение), что механизм слияния принуждает the common ancestor быть ревизией, которую вы пытаетесь вернуть, и the other branch является родителем этой версии.