Як зливається git після вишні?

Уявімо собі, що у нас є masterфілія.

Тоді ми створюємо newbranch

git checkout -b newbranch

і зробіть два нові зобов’язання newbranch: commit1 та commit2

Потім переходимо на майстер і робимо cherry-pick

git checkout master
git cherry-pick hash_of_commit1

Дивлячись на те, gitkми бачимо, що commit1 та його вишнева версія мають різні хеши, тому в технічному відношенні це два різні коміти.

Нарешті ми зливаємось newbranchу master:

git merge newbranch

і бачите, що ці два коміти з різними хешами були об'єднані без проблем, хоча вони означають, що одні й ті ж зміни слід застосовувати двічі, тому один з них повинен зазнати невдачі.

Чи дійсно git робить розумний аналіз вмісту фіксації під час об'єднання та вирішує, що зміни не слід застосовувати двічі або ці комірки позначаються внутрішньо як пов’язані між собою?

Коротка відповідь

Не хвилюйтесь, Git впорається з цим.

Довга відповідь

На відміну, наприклад, SVN ¹ , Git не зберігає комісії у форматі дельти, а базується на ^{моментах 2,3} . У той час як SVN наївно намагався застосувати кожну об'єднану комісію як патч (і не вдалося з точної причини, яку ви описали), Git, як правило, може впоратися з цим сценарієм.

Під час об'єднання Git намагатиметься поєднати знімки обох HEAD у новий знімок. Якщо частина коду або файл однакові в обох знімках (тобто тому, що комісія вже була вибрана вишнею), Git не торкнеться її.

Джерела

¹ Skip-Deltas в підривній основі
² Основи Git
³ Модель об'єкта Git

Після такого злиття у вас можуть виникла вишні в історії два рази.

Рішення для запобігання цьому я цитую в статті, яка рекомендує для гілок з дублікатами (вишневий) зобов’язується використовувати ребайт перед об'єднанням:

git merge after git cherry-pick: уникати повторюваних комітетів

Уявіть, у нас є головна гілка та гілка b:

   o---X   <-- master
    \
     b1---b2---b3---b4   <-- b

Тепер нам терміново потрібні доручення b1 і b3 у master, але не решта доручень у b. Тож, що ми робимо, це перевірити головну гілку та вишневий комітет b1 та b3:

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

Результатом буде:

   o---X---b1'---b3'   <-- master
    \
     b1---b2---b3---b4   <-- b

Скажімо, ми робимо ще один вчинок на майстра і отримуємо:

   o---X---b1'---b3'---Y   <-- master
    \
     b1---b2---b3---b4   <-- b

Якби ми тепер об'єднали гілку b в головну:

$ git merge b

Ми отримаємо наступне:

   o---X---b1'---b3'---Y--- M  <-- master
     \                     /
      b1----b2----b3----b4   <-- b

Це означає, що зміни, внесені b1 і b3, з’являлися б двічі за всю історію. Щоб уникнути того, що ми можемо перезавантажити замість об’єднання:

$ git rebase master b

Що б дало:

   o---X---b1'---b3'---Y   <-- master
                        \
                         b2'---b4'   <-- b

Нарешті:

$ git checkout master
$ git merge b

дає нам:

   o---X---b1'---b3'---Y---b2'---b4'   <-- master, b

Виправлення EDIT, що передбачаються коментарем Девіда Лемона