Зливання в Git зазвичай проходить доволі легко. Оскільки Git дозволяє легко зливати іншу гілку декілька разів, ви можете працювати з дуже довготривалою гілкою, і в той же час оновлювати її в процесі роботи, та часто розв’язувати маленькі конфлікти замість того, щоб бути враженим величезним конфліктом наприкінці роботи з нею.
Утім, іноді трапляються й хитромудрі конфлікти. На відміну від інших систем контролю версій, Git не намагається бути надто розумним щодо розв’язання конфліктів. Філософія Git — бути розумним, коли злиття можна зробити однозначно, проте, якщо є конфлікт, Git не намагається бути розумним та автоматично його вирішити. Отже, якщо ви надто зволікаєте зі злиттям двох гілок, що розходяться швидко, у вас можуть виникнути проблеми.
У цій секції, ми розглянемо деякі з тих проблем, що можуть виникнути, та які утиліти Git допомагають впоратись з багатьма складними ситуаціями. Ми також розглянемо деякі інші, нестандартні типи зливань, які ви можете робити, а також як відмовитися від вже зробленого зливання.
Хоч ми й розглянули деякі основи розв’язання конфліктів зливання в ch03-git-branching.asc, для складніших конфліктів Git пропонує декілька утиліт, що допоможуть вам збагнути що коїться та як краще мати справу з конфліктом.
Спершу, якщо це взагалі можливо, спробуйте зробити вашу робочу директорію чистою до того, як робити зливання, що призводять до конфліктів. Якщо у вас є незавершені зміни, або зробіть коміт до тимчасової гілки, або сховайте їх (stash). Таким чином ви зможете скасувати будь-яку з ваших спроб. Якщо у вас є незбережені зміни у робочій директорій, коли ви намагаєтесь зробити зливання, деякі з наступних інструкцій можуть сприяти втраті вашої праці.
Розгляньмо дуже простий приклад. У нас є надпростий файл Ruby, що друкує 'hello world'.
#! /usr/bin/env ruby
def hello
puts 'hello world'
end
hello()У нашому репозиторії, ми створюємо нову гілку whitespace та замінюємо всі Unix символи нового рядка на варіант DOS, тобто змінюємо кожен рядок файлу, проте виключно пробільні символи.
Потім ми змінюємо рядок hello world'' на hello mundo''.
$ git checkout -b whitespace
Switched to a new branch 'whitespace'
$ unix2dos hello.rb
unix2dos: converting file hello.rb to DOS format ...
$ git commit -am 'converted hello.rb to DOS'
[whitespace 3270f76] converted hello.rb to DOS
1 file changed, 7 insertions(+), 7 deletions(-)
$ vim hello.rb
$ git diff -b
diff --git a/hello.rb b/hello.rb
index ac51efd..e85207e 100755
--- a/hello.rb
+++ b/hello.rb
@@ -1,7 +1,7 @@
#! /usr/bin/env ruby
def hello
- puts 'hello world'
+ puts 'hello mundo'^M
end
hello()
$ git commit -am 'hello mundo change'
[whitespace 6d338d2] hello mundo change
1 file changed, 1 insertion(+), 1 deletion(-)Тепер перейдемо назад до гілки та додамо якийсь опис цієї функції.
$ git checkout master
Switched to branch 'master'
$ vim hello.rb
$ git diff
diff --git a/hello.rb b/hello.rb
index ac51efd..36c06c8 100755
--- a/hello.rb
+++ b/hello.rb
@@ -1,5 +1,6 @@
#! /usr/bin/env ruby
+# prints out a greeting
def hello
puts 'hello world'
end
$ git commit -am 'document the function'
[master bec6336] document the function
1 file changed, 1 insertion(+)Тепер ми спробуємо злити до гілки whitespace та отримаємо конфлікти через зміни пробільних символів.
$ git merge whitespace
Auto-merging hello.rb
CONFLICT (content): Merge conflict in hello.rb
Automatic merge failed; fix conflicts and then commit the result.Тепер у нас є декілька варіантів.
По-перше, розповімо, як вийти з цього становища.
Можливо, ви не очікували конфліктів, та не дуже бажаєте вирішувати ситуацію зараз, ви можете просто припинити злиття за допомогою git merge --abort.
$ git status -sb
## master
UU hello.rb
$ git merge --abort
$ git status -sb
## masterОпція git merge --abort намагається повернутися до стану, в якому ви були до початку зливання.
Єдиний випадок, коли це може не вийти бездоганно — якщо у вас були несховані незбережені зміни в робочій директорії, коли ви почали злиття, інакше все пройде без проблем.
Якщо з будь-якої причини ви просто бажаєте почати все з початку, ви можете виконати git reset --hard HEAD, і ваше сховище повернеться до стану останнього коміту.
Памʼятайте, що будь-які не збережені в коміті зміни будуть втрачені, отже переконайтеся, що всі локальні зміни вам не потрібні.
У цьому окремому випадку, конфлікти пов’язані з пробільними символами. Ми знаємо про це, адже випадок простий, проте це доволі легко побачити в реальних ситуаціях, подивившись на конфлікт: кожен рядок видалено з одного боку та знову додано з іншого. Без додаткових опцій, Git розглядає всі рядки як змінені, отже не може злити файли.
Втім, типова стратегія зливання може приймати опції, а декілька з них про правильне ігнорування зміни пробільних символів.
Якщо ви бачите, що у вас купа проблем з пробільними символами при злитті, ви можете просто припинити його та спробувати ще раз, цього разу з -Xignore-all-space або -Xignore-space-change.
Перша опція цілковито ігнорує пробільні символи при порівнянні рядків, а друга сприймає послідовності одного чи більше пробільних символів як рівнозначні.
$ git merge -Xignore-space-change whitespace
Auto-merging hello.rb
Merge made by the 'recursive' strategy.
hello.rb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)Оскільки в даному випадку, справжні зміни файла не конфліктують, щойно ми проігноруємо зміни пробільних символів, злиття пройде чудово.
Це просто рятує життя, якщо хтось з вашої команди подеколи полюбляє замінити пробіли на таби чи навпаки.
Хоч Git і може впоратися з обробкою пробільних символів доволі якісно, існують інші типи змін, які Git певно не можне обробити автоматично, проте самі зміни зроблені автоматично. Наприклад, вдамо, що Git не зміг впоратися зі змінами пробілів, та ми маємо зробити це самі.
Що нам насправді треба зробити — це прогнати файл, який ми намагаємося злити, через програму dos2unix до того, як починати власне злиття файла.
То як нам це зробити?
Спочатку нам треба потрапити до стану конфлікту злиття. Потім нам треба отримати копії нашої версії файла, їхньої версії (з гілки, яку ми зливаємо до нашої) та спільної версії (звідки обидві сторони розгалузились). Далі ми бажаємо виправити або їхній варіант або наш та спробувати злити знову лише цей один файл.
Отримати три версії файла насправді доволі просто.
Git зберігає кожну з цих версій в індексі під станами'' (stages), які мають пов’язані з ними номери.
Стан 1 — це спільний предок, стан 2 — це ваша версія, а стан 3 — з `MERGE_HEAD, версія, яку ви зливаєте до себе (їхня'', theirs)
Ви можете витягнути копію кожної з цих версій конфліктного файлу за допомогою команди git show зі спеціальним синтактом.
$ git show :1:hello.rb > hello.common.rb
$ git show :2:hello.rb > hello.ours.rb
$ git show :3:hello.rb > hello.theirs.rbЯкщо ви бажаєте чогось суворішого, скористайтесь кухонною командою ls-files -u, щоб отримати власне SHA-1 суми Git блобів кожного з цих файлів
$ git ls-files -u
100755 ac51efdc3df4f4fd328d1a02ad05331d8e2c9111 1 hello.rb
100755 36c06c8752c78d2aff89571132f3bf7841a7b5c3 2 hello.rb
100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3 hello.rb:1:hello.rb — це просто скорочення для пошуку SHA-1 цього блобу.
Тепер у нас є зміст всіх трьох станів у нашій робочій директорії, ми можемо вручну виправити їхню версію — усунути проблему з пробільними символами, та ще раз злити файл за допомогою маловідомої команди git merge-file, яка робить саме це.
$ dos2unix hello.theirs.rb
dos2unix: converting file hello.theirs.rb to Unix format ...
$ git merge-file -p \
hello.ours.rb hello.common.rb hello.theirs.rb > hello.rb
$ git diff -b
diff --cc hello.rb
index 36c06c8,e85207e..0000000
--- a/hello.rb
+++ b/hello.rb
@@@ -1,8 -1,7 +1,8 @@@
#! /usr/bin/env ruby
+# prints out a greeting
def hello
- puts 'hello world'
+ puts 'hello mundo'
end
hello()Тепер ми гарно злили файл.
Насправді, це працює навіть краще, ніж опція ignore-space-change, адже зміни пробільних символів виправлено до злиття, а не просто проігноровано.
У злитті з ignore-space-change, ми в результаті отримали декілька рядків з DOS символами нового рядка, що призвело до змішання.
До того, як завершувати цей коміт, ви можете поглянути, що саме змінилось між однією чи іншою стороною: ви можете попросити git diff порівняти те, що ви збираєтесь зберегти з вашої робочої директорії як результат злиття, з будь-яким з цих станів.
Пройдімось по ним усім.
Щоб порівняти результат з тим, що було до зливання, іншими словами, щоб побачити, що саме з’явилось від злиття, можна виконати git diff --ours
$ git diff --ours
* Unmerged path hello.rb
diff --git a/hello.rb b/hello.rb
index 36c06c8..44d0a25 100755
--- a/hello.rb
+++ b/hello.rb
@@ -2,7 +2,7 @@
# prints out a greeting
def hello
- puts 'hello world'
+ puts 'hello mundo'
end
hello()Отже тут ми легко можемо побачити, що саме сталося в нашій гілці, що ми насправді змінюємо у файлі цим злиттям: змінюємо один рядок.
Якщо ми бажаємо побачити, чим результат зливання відрізняється від того, що було на їхній стороні, можемо виконати git diff --theirs.
У цьому й наступному прикладі, ми маємо використати -b, щоб прибрати пробільні символи, бо порівняння проходить зі збереженим у Git, а не з нашим очищеним файлом hello.theirs.rb.
$ git diff --theirs -b
* Unmerged path hello.rb
diff --git a/hello.rb b/hello.rb
index e85207e..44d0a25 100755
--- a/hello.rb
+++ b/hello.rb
@@ -1,5 +1,6 @@
#! /usr/bin/env ruby
+# prints out a greeting
def hello
puts 'hello mundo'
endНарешті, ви можете побачити, як файл змінився з обох сторін за допомогою git diff --base.
$ git diff --base -b
* Unmerged path hello.rb
diff --git a/hello.rb b/hello.rb
index ac51efd..44d0a25 100755
--- a/hello.rb
+++ b/hello.rb
@@ -1,7 +1,8 @@
#! /usr/bin/env ruby
+# prints out a greeting
def hello
- puts 'hello world'
+ puts 'hello mundo'
end
hello()Тепер ми можемо використати команду git clean, щоб прибрати зайві файли, що ми їх створили для зливання вручну, бо вони більше не потрібні.
$ git clean -f
Removing hello.common.rb
Removing hello.ours.rb
Removing hello.theirs.rbМожливо, ми наразі не задоволені розв’язанням конфлікту з якихось причин, або можливо редагування вручну однієї чи обох сторін досі не вийшло та нам треба більше контексту.
Змінімо трохи наш приклад. У цьому прикладі, у нас є дві більш довготривалі гілки, у кожній по декілька комітів, проте при зливанні створюють конфлікт саме за змістом.
$ git log --graph --oneline --decorate --all
* f1270f7 (HEAD, master) update README
* 9af9d3b add a README
* 694971d update phrase to hola world
| * e3eb223 (mundo) add more tests
| * 7cff591 add testing script
| * c3ffff1 changed text to hello mundo
|/
* b7dcc89 initial hello world codeТепер у нас три унікальних коміти, які є лише в гілці master, та три інших коміти, які є в гілці mundo.
Якщо ми спробуємо злити mundo, то отримаємо конфлікт.
$ git merge mundo
Auto-merging hello.rb
CONFLICT (content): Merge conflict in hello.rb
Automatic merge failed; fix conflicts and then commit the result.Ми хотіли б побачити, у чому власне конфлікт. Якщо відкрити файл, то побачимо щось таке:
#! /usr/bin/env ruby
def hello
<<<<<<< HEAD
puts 'hola world'
=======
puts 'hello mundo'
>>>>>>> mundo
end
hello()Обидві сторони зливання додали зміст до цього файлу, проте деякі з комітів змінили файл в одному місці, що й спричинило цей конфлікт.
Дослідімо декілька утиліт у вашому розпорядженні, щоб визначити, як виник цей конфлікт. Можливо, як саме варто розв’язати конфлікт не є очевидним. Вам потрібно більше контексту.
Одна з корисних команд — git checkout з опцією --conflict.
Ця команда ще раз отримає файл, та замінить позначки конфлікту (conflict markers).
Це може бути корисним, якщо ви бажаєте відновити позначки та спробувати розв’язати їх знову.
Ви можете встановити --conflict значення diff3, або merge (що є типовим значенням).
Якщо передати diff3, то Git використає трохи іншу версію позначок конфлікту: не тільки надасть вам вашу'' та їхню'' версії, а ще й ``базову'' версію до файлу, щоб надати вам більше контексту.
$ git checkout --conflict=diff3 hello.rbПісля виконання, файл стане виглядати так:
#! /usr/bin/env ruby
def hello
<<<<<<< ours
puts 'hola world'
||||||| base
puts 'hello world'
=======
puts 'hello mundo'
>>>>>>> theirs
end
hello()Якщо вам подобається такий формат, ви можете зробити його типовим для майбутніх конфліктів злиття, якщо встановите налаштування merge.conflictstyle у значення diff3.
$ git config --global merge.conflictstyle diff3Команда git checkout також приймає опції --ours та --theirs, які є дійсно швидким засобом вибору лише однієї сторони, взагалі без зливання іншої.
Це особливо корисно для конфліктів двійкових файлів, адже ви можете просто вибрати одну сторону, або коли ви хочете злити окремі файли з іншої гілки - ви можете злити, а потім отримати (checkout) окремі файли з однієї сторони до створення коміту.
Ще одна корисна утиліта при розв’язанні конфліктів злиття — git log.
Вона може допомогти вам отримати інформацію про те, що могло сприяти конфлікту.
Переглянути трохи історії, щоб запам’ятати, чому два рядки розробки зачепили одну область коду, може бути дуже корисним подеколи.
Щоб отримати повний список усіх унікальних комітів, що є у будь-якій з конфліктуючих гілок, можна використати синтаксис ``потрійної крапки'', про який ми дізналися в ch07-git-tools.asc.
$ git log --oneline --left-right HEAD...MERGE_HEAD
< f1270f7 update README
< 9af9d3b add a README
< 694971d update phrase to hola world
> e3eb223 add more tests
> 7cff591 add testing script
> c3ffff1 changed text to hello mundoЦе гарний список усіх шести комітів, а також з якої лінії розробки надійшов кожен коміт.
Ми можемо ще спростити список так, щоб це надало нам більш точний контекст.
Якщо додати опцію --merge до git log, вона покаже лише ті коміти з обох сторін злиття, які зачепили файл, в якому наразі є конфлікти.
$ git log --oneline --left-right --merge
< 694971d update phrase to hola world
> c3ffff1 changed text to hello mundoЯкщо виконати це з опцією -p, отримаємо лише зміни у файлах, які опинились у конфлікті.
Це може бути дійсно корисним у швидкому надаванні контексту, що допоможе зрозуміти причини конфлікту та як його розумно розв’язати.
Оскільки Git індексує будь-які успішні результати злиття, коли ви виконуєте git diff у стані конфлікту злиття, ви отримуєте лише конфліктуючі зміни.
Це може бути корисним, щоб побачити, що вам ще треба розв’язати.
Якщо виконати git diff одразу після конфлікту злиття, то вона видасть інформацію в доволі унікальному форматі різниці.
$ git diff
diff --cc hello.rb
index 0399cd5,59727f0..0000000
--- a/hello.rb
+++ b/hello.rb
@@@ -1,7 -1,7 +1,11 @@@
#! /usr/bin/env ruby
def hello
++<<<<<<< HEAD
+ puts 'hola world'
++=======
+ puts 'hello mundo'
++>>>>>>> mundo
end
hello()Формат називається Поєднана різниця'' (combined diff) та видає дві колонки даних навпроти кожного рядка.
Перша колонка показує вам, якщо рядок змінився (доданий чи вилучений) між вашою'' гілкою та файлом у робочій директорії, а друга колонка робить те саме між ``їхньою'' гілкою та робочою директорією.
Отже в цьому прикладі можна побачити, що рядки <<<<<<< та >>>>>>> є в робочій копії, проте їх нема в жодній зі сторін зливання.
Це має сенс, адже утиліта злиття додала їх для нас, але від нас очікується їх вилучення.
Якщо розв’язати конфлікт та виконати git diff знову, ми побачимо схожий результат, проте трохи корисніший.
$ vim hello.rb
$ git diff
diff --cc hello.rb
index 0399cd5,59727f0..0000000
--- a/hello.rb
+++ b/hello.rb
@@@ -1,7 -1,7 +1,7 @@@
#! /usr/bin/env ruby
def hello
- puts 'hola world'
- puts 'hello mundo'
++ puts 'hola mundo'
end
hello()Це показує нам, що hola world'' був на нашій стороні, проте не в робочій копії; hello mundo'' був на їхній стороні, проте не в робочій копії; та нарешті, ``hola mundo'' не був у жодній зі сторін, проте є в робочій копії.
Це може бути корисним, щоб переглянути розв’язання конфлікту до створення коміту.
Ви також можете отримати таке від git log для будь-якого вже зробленого зливання, щоб побачити як щось було розв’язано.
Git зробить видрук у цьому форматі, якщо виконати git show для коміту злиття, або якщо додати опцію --cc до git log -p (яка типово показує лише латки для комітів не злиття).
$ git log --cc -p -1
commit 14f41939956d80b9e17bb8721354c33f8d5b5a79
Merge: f1270f7 e3eb223
Author: Scott Chacon <[email protected]>
Date: Fri Sep 19 18:14:49 2014 +0200
Merge branch 'mundo'
Conflicts:
hello.rb
diff --cc hello.rb
index 0399cd5,59727f0..e1d0799
--- a/hello.rb
+++ b/hello.rb
@@@ -1,7 -1,7 +1,7 @@@
#! /usr/bin/env ruby
def hello
- puts 'hola world'
- puts 'hello mundo'
++ puts 'hola mundo'
end
hello()Тепер, коли ви знаєте, як створити коміт злиття, ви напевно зробите якусь помилку. Одна з чудових речей роботи з Git — що це нормально робити помилки, адже їх можливо (та зазвичай легко) виправити.
Коміти зливання тут не відрізняються.
Скажімо, ви почали працювати над тематичною гілкою, та випадково злили її до master, і тепер історія комітів виглядає так:
Є два підходи до цієї проблеми, у залежності від бажаного результату.
Якщо небажаний коміт зливання існує лише у вашому локальному репозиторії, найлегше та найкраще рішення — пересунути гілки так, щоб вони вказували на що ви забажаєте.
У більшості випадків, якщо одразу після помилки git merge, виконати git reset --hard HEAD~, то вказівники гілок будуть скинуті і будуть виглядати так:
git reset --hard HEAD~Ми розглядали reset у ch07-git-tools.asc, отже, вам має бути неважко зрозуміти, що тут сталося.
Ось швидке повторення: reset --hard зазвичай робить наступні кроки:
-
Пересунути гілку, на яку вказує HEAD. У даному випадку, ми бажаємо пересунути
masterдо того, де вона була до коміту злиття (C6). -
Скопіювати HEAD до індекс.
-
Скопіювати індекс до робочої директорії.
Недолік цього підходу є те, що це переписування історії, що може стати проблемою в спільному репозиторії.
Прогляньте ch03-git-branching.asc для докладного опису того, що може статися; коротка версія така: якщо інші люди мають коміти, які ви переписуєте, вам варто уникати reset.
Цей підхід також не спрацює, якщо інші коміти були створені після злиття; переміщення посилань у результаті втратить ці зміни.
Якщо переміщення вказівників гілок не спрацює для вас, Git дає ще один варіант: створити новий коміт, що скасовує всі зміни з існуючого коміту. Git називає цю операцію ``вивертання'' (revert), і в цьому конкретному випадку, треба викликати його так:
$ git revert -m 1 HEAD
[master b1d8379] Revert "Merge branch 'topic'"Опція -m 1 вказує, який батько є `стрижневим'' (mainline) та має бути збереженим.
Якщо виконати злиття до `HEAD (git merge topic), новий коміт матиме двох батьків: перший це HEAD (C6), а другий — останній коміт гілки, яку ви зливаєте (C4).
У даному випадку, ми бажаємо скасувати всі зміни, спричинені у батьку #2 (C4), проте зберігти весь зміст з батька #1 (C6).
Історія з виверненим комітом виглядає так:
git revert -m 1Новий коміт ^M має точно такий зміст, як C6, отже починаючи звідти, усе нібито злиття ніколи не було, окрім того, що тепер не злиті коміти досі присутні в історії HEAD.
Git заплутається, якщо ви спробуєте злити topic до master знову:
$ git merge topic
Already up-to-date.У гілці topic немає нічого недосяжного з гілки master.
Гірше того, якщо ви додасте щось до topic, та зіллєте знову, Git візьме лише зміни після виверту злиття:
Найкращій вихід — це вивернути виворіт першого злиття, адже тепер ви бажаєте повернути зміни, які ви були вивернули, потім створити новий коміт злиття:
$ git revert ^M
[master 09f0126] Revert "Revert "Merge branch 'topic'""
$ git merge topic
У цьому прикладі, M та ^M взаємно знищились.
^^M в результаті зливає зміни C3 та C4, а C8 зливає зміну C7, отже тепер topic повністю злито.
Досі ми розглядали нормальні злиття двох гілок, що зазвичай обробляються тим, що називається стратегією злиття ``recursive''. Одначе, існують й інші методи зливати гілки разом. Швидко розгляньмо декілька з них.
Почнімо з додаткових можливостей звичайного режиму зливання `recursive''.
Ми вже зустрічали опції `ignore-all-space та ignore-space-change, які передаються до -X, проте ми також можемо сказати Git надавати перевагу одній чи іншій стороні, коли він бачить конфлікт.
Без додаткових опцій, коли Git бачить конфлікт між двома гілками при зливанні, він додасть позначки конфлікту до вашого коду та позначить файл конфліктним, та дасть вам його розв’язати.
Якщо ви бажаєте, щоб Git просто вибрав якусь сторону та проігнорував іншу замість того, щоб залишати вам вручну розв’язувати конфлікт, ви можете передати команді merge опцію -Xours чи -Xtheirs.
Якщо це зробити, Git не буде додавати позначки конфлікту. Будь-які зміни, що можна злити, будуть злиті. Для будь-яких конфліктуючих змін, Git просто вибере сторону, яку ви задали, включно з двійковими файлами.
Якщо ми повернемося до попереднього прикладу ``hello world'', ми можемо бачити, що зливання нашої гілки призводить до конфліктів.
$ git merge mundo
Auto-merging hello.rb
CONFLICT (content): Merge conflict in hello.rb
Resolved 'hello.rb' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.Проте якщо виконати з -Xours або -Xtheirs, конфлікту не буде.
$ git merge -Xours mundo
Auto-merging hello.rb
Merge made by the 'recursive' strategy.
hello.rb | 2 +-
test.sh | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
create mode 100644 test.shУ даному випадку, замість отримання позначок конфлікту у файлі з hello mundo'' з одного боку та hola world'' з іншого, Git просто обере ``hola world''.
Однак, усі інші неконфліктуючі зміни на цій гілці успішно злиті.
Цю опцію також можна передати команді git merge-file, яку ми бачили раніше, наприклад виконавши git merge-file --ours для окремих зливань файлів.
Якщо вам потрібно щось схоже, проте щоб Git навіть не намагався зливати зміни з іншої сторони, є більш драконівська опція, а саме стратегія злиття ours''.
Це не те саме, що опція рекурсивного (recursive) злиття ours''.
Це фактично зробить підроблене злиття. Буде записано новий коміт злиття з обома гілками в якості батьків, проте на гілку, яку ви зливаєте, навіть не глянуть. У якості результату злиття буде записано саме код вашої поточної гілки.
$ git merge -s ours mundo
Merge made by the 'ours' strategy.
$ git diff HEAD HEAD~
$Як бачите, між гілкою, на якій ви були, та результатом зливання немає ніякої різниці.
Це може бути корисним для введення Git в оману, бо він буде вважати, що гілка вже злита при подальших зливаннях.
Наприклад, якщо ви відгалузили гілку release, та зробили якусь роботу в ній, яку ви потім забажаєте злити до гілки master.
У той же час, якесь виправлення з master має бути додано до вашої гілки release.
Ви можете злити виправлення до гілки release і також merge -s ours ту ж гілку до гілки master (хоча виправлення вже там), тоді при подальшому зливанні гілки release, ніяких конфліктів від цього виправлення не виникне.