выбор вишни

Верно ли, что F' = (F-B) + Z?

Нет, это также внесет изменения, внесенные в C, D и E.

git-cherry-pick работает, изолируя уникальные изменения в коммите, которые будут отобраны (например, F-E в этом примере, игнорируя дополнительных предков, включая базу слияния), и применяя их к цели.

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

Например, если E является родителем коммита, который нужно выбрать, и его содержимое (действующее как общий предок):

Line 1
Line 2
Line 3
Line 4
Line 5

Например, если F — это коммит, который нужно выбрать, и его содержимое:

Line 1
Line 2
Line Three
Line 4
Line 5

И цель вишневого выбора Z:

LINE 1
Line 2
Line 3
Line 4
Line 5!

Затем результаты трехстороннего слияния (с аннотациями о том, откуда взялась каждая строка):

LINE 1
Line 2
Line Three
Line 4
Line 5!

возвращаться

Верно ли, что D' = G - D?

Да грубо говоря. Изменения, которые были уникальными для D, были удалены из G. Как и git-cherry-pick, git-revert реализовано с использованием трехстороннего слияния, хотя на этот раз фиксация для возврата рассматривается как общий предок, одна сторона — текущая фиксация, а другая — родительская фиксация для возврата.

Это будет означать, что если строка между фиксацией для возврата и текущей фиксацией идентична, вместо нее будет выбрана строка из ее родителя.

Если содержимое D, коммит для возврата действует как общий предок, и его содержимое:

Line 1
Line 2
Line THREE
Line 4
Line FIVE

И содержимое C (родителя D):

Line 1
Line 2
Line 3
Line 4
Line 5

И содержимое G было изменено дальше, и его содержимое таково:

Line One
Line 2
Line THREE
Line 4
Line FIVE

Тогда результаты трехстороннего слияния будут такими:

Line One
Line 2
Line 3
Line 4
Line 5

Это результат использования уникальных строк в родительском C и целевом G.

Объединить коммиты

Как отмечает torek (ниже), поскольку оба этих механизма включают использование родительской фиксации, они ломаются, когда есть более одного родительского коммита. (То есть рассматриваемая фиксация является слиянием и имеет несколько родителей.) В этом случае вам нужно будет указать git какой родитель учитывать (используя флаг -m).

Конфликты

Конечно, любой из этих механизмов может вызывать конфликты. Например, если текущий конфликт был дальше изменен, вам придется разрешать конфликты. Например, если в примере с откатом (выше) последующая фиксация также изменила строку 5, то G на самом деле была такой:

Line One
Line 2
Line THREE
Line 4
LINE FIVE!

Тогда был бы конфликт. Рабочий каталог (объединенный файл) будет:

Line One
Line 2
Line 3
Line 4
<<<<<<<
LINE FIVE!
=======
Line 5
>>>>>>>

И вам нужно будет решить, хотите ли вы исходное изменение (Line 5) или новейшее изменение (LINE FIVE!).

Это очень просто понять так:

cherry-pick

выбрать коммит (из любой ветки или даже свободный коммит) выбрать этот коммит и поместить его в мою текущую ветку, другими словами - взять любой коммит из любого места в репозитории добавить перенести его в мою ветку

revert

Отмените любую фиксацию. он «отменит» любые изменения, сделанные в фиксации, отменив их, если вы знаете, что такое патч, чтобы вы могли видеть, что он меняет знак в патче - becommig + и наоборот. ваши изменения «отменяются», и изменения отменяются.

Команда git revert отменяет зафиксированный моментальный снимок.

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

Это prevents Git from losing history, которое важно для целостности вашей истории изменений и для надежного сотрудничества.

Верно ли, что F' = (F-B) + Z?

Это просто означает, что теперь в нижней ветке у вас также есть патч, созданный в коммите F, ваша нижняя ветка содержит его изменения + изменения, которые были сделаны в коммите F (и только их, никаких других коммитов рядом с Ф)

Верно ли, что D' = G – D?

Не совсем - это означает, что теперь у вас есть коммит D, и после нескольких коммитов у вас есть отмена этого коммита, в репозитории у вас все еще есть 2 коммита, но код не изменится (изменить + отменить на 2 отдельных коммитах)

С Git 2.29 (4 квартал 2020 г.) исправлена ​​аналогичная ситуация.

См. коммит 087c616, коммит 409f066, (20 сентября 2020 г.), автор Брайан М. carlson (bk2204).
^{(Объединено Junio ​​C Hamano -- gitster --< /a> в commit c5a8f1e, 29 сентября 2020 г.)}

docs: объясните, почему возвраты не всегда применяются при слиянии

^{Подписано: Брайан М. Карлсон}

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

У нас уже есть документация о том, как это работает, в git merge. ^(man), но это видно по частоте с чем это спрошено, что трудно понять.
Мы также не объясняем пользователям, что им лучше сделать в этом случае rebase, который сделает то, что они задумали.
Добавим запись в FAQ, сообщая пользователям, что происходит, и советуя им использовать rebase здесь.

gitfaq теперь включает в свою справочную страницу:

Если я внесу изменения в две ветки, но верну их в одну, почему слияние этих веток включает изменение?

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

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

Если это проблема для вас, вы можете вместо этого выполнить перебазирование, перебазировав ветку с возвратом на другую ветку.
Перебазирование в этом сценарии отменит изменение, потому что перебазирование применяется к каждому отдельному коммиту, включая revert.
Обратите внимание, что перебазирование переписывает историю, поэтому вам следует избегать перебазирования опубликованных веток, если вы не уверены, что вам это удобно.
См. раздел NOTES в git rebase для более подробной информации.