Подтвердить что ты не робот

Слияния в Git симметричны?

Допустим, у нас есть две ветки (B и C), которые расходятся с общим предком A. Слияние с B на C приведет к тому же результату, что и слияние от C до B?

  A
  |
 / \
B   C

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

Чтобы уточнить, я знаю, что фактическое слияние приводит к "зеркальным изображениям" друг от друга в зависимости от направления. Я просто спрашиваю о автоматически разрешенных конфликтах.

4b9b3361

Ответ 1

Ответ: да для слияния по умолчанию. Трехстороннее слияние находит общего предка, а затем применяет различия с обеих сторон, операцию, которая не зависит от порядка. Тема слияния и коммутации вызвала увлекательную дискуссию в git списке (если вы в этом заняты). Примечание B into C и C into B должны быть симметричными, но то же самое нельзя сказать и для (B into C) into A по сравнению с B into (C into A).


Чтобы разработать немного больше, основываясь на комментарии Винса ниже и прокомментировать этот вопрос, между B into C и C into B будут наблюдаться две заметные различия, ни одна из которых не влияет на автоматическое разрешение слияния, упомянутое в вопросе.

Во-первых, история будет другой. Родители слияния будут меняться в зависимости от порядка слияния. Для этих примеров я собираюсь использовать "first_branch" и "second_branch", поэтому я могу зарезервировать буквы для представления коммитов.

git checkout first_branch && git merge second_branch

E <- merge commit
|\
| D <- second_branch tip
| |
| C <- another commit on second_branch 
| |
| B <- and another
|/
A <- first_branch tip before the merge

В этом случае "первый родительский элемент" E, E^1 является концом first_branch перед слиянием. second_branch является "вторым родителем" слияния, ака E^2. Теперь рассмотрим обратное:

git checkout second_branch && git merge first_branch

E <- merge commit
|\
| D <- first_branch tip
| |
| C <- another commit on first_branch 
| |
| B <- and another
|/
A <- second_branch tip before the merge

Родители меняются на противоположные. E^1 является вершиной second_branch до слияния. E^2 - это вершина first_branch.

Во-вторых, порядок отображения конфликтов будет отменен. В первом случае конфликт может выглядеть так:

<<<<<<< HEAD
This line was added from the first_branch branch.
=======
This line was added from the second_branch branch.
>>>>>>> second_branch

Во втором случае тот же конфликт будет выглядеть так:

<<<<<<< HEAD
This line was added from the second_branch branch.
=======
This line was added from the first_branch branch.
>>>>>>> first_branch

Ни одно из этих различий не влияет на автоматическое разрешение слияния, но они появляются при изменении порядка трехстороннего слияния.

Ответ 2

Это зависит от того, что вы подразумеваете под "тем же результатом". С точки зрения контента, предполагая, что конфликтов нет или все существующие конфликты решаются точно так же, содержимое полученного нового коммита должно быть одинаковым.

Однако, с точки зрения топологии истории, они очень разные. Если вы находитесь на ветке B и сливаетесь на C, HEAD of B перемещается, чтобы указать на фиксацию слияния, но C остается там, где он есть. И наоборот, если вы находитесь на C и сливаетесь в B, C HEAD перемещается, а B остается там, где он есть. Таким образом, конечная топология очень различна, что имеет последствия для будущего развития в любой из ветвей, даже если содержание нового фиксации идентично в любом случае.

Ответ 3

нет, я думаю, что он не будет симметричным. Сначала вы можете установить параметр стратегии слияния, особенно в вашем случае theirs или ours, который определяет, будут ли выбраны B или C.

В автоматических слияниях, я думаю, например, удаленная ветка имеет приоритет над вашими изменениями, если вы сливаетесь в свои, поэтому означает, что вызов git merge C из B приведет к выбору C-изменений. Хотя я не уверен на 100%, поэтому вы можете попробовать это сами и сообщить нам.