Чи існує "їхня" версія "git merge -s our"?

При об'єднанні тематичної гілки "B" в "A" за допомогою git mergeя отримую деякі конфлікти. Я знаю, що всі конфлікти можна вирішити за допомогою версії в "В".

Мені відомо git merge -s ours. Але я хочу щось подібне git merge -s theirs.

Чому його не існує? Як я можу досягти такого ж результату після суперечливого злиття з існуючими gitкомандами? ( git checkoutкожен неперероблений файл із B)

ОНОВЛЕННЯ: "Рішення" просто відкинути що-небудь із гілки A (точка злиття комісії в B-версію дерева) - це не те, що я шукаю.

Додати -Xопцію в theirs. Наприклад:

git checkout branchA
git merge -X theirs branchB

Все злиється бажаним чином.

Єдине, що я бачив, це викликає проблеми, якщо файли були видалені з branchB. Вони виявляються конфліктами, якщо щось інше, ніж git, видалили.

Виправити це легко. Просто запустіть git rmз ім'ям усіх видалених файлів:

git rm {DELETED-FILE-NAME}

Після цього -X theirsслід працювати так, як очікувалося.

Звичайно, виконання фактичного видалення за допомогою git rmкоманди запобіжить виникненню конфлікту в першу чергу.

Примітка : Існує також довший варіант форми.

Щоб використовувати його, замініть:

-X theirs

з:

--strategy-option=theirs

Можливе і перевірене рішення для об'єднання відділенняB у нашу перевірену галузьA:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

Щоб автоматизувати його, ви можете зафіксувати його в сценарій, використовуючи в якості аргументів branchA і branchB.

Це рішення зберігає перше і друге батьківське об'єднання злиття так, як ви і очікували git merge -s theirs branchB.

Старіші версії git дозволяли вам використовувати "їхню" стратегію злиття:

git pull --strategy=theirs remote_branch

Але це було знято, як пояснив у цьому повідомленні Хуніо Хамано (супроводжувач Git). Як зазначено у посиланні, замість цього ви зробите це:

git fetch origin
git reset --hard origin

Однак остерігайтеся, що це відрізняється від фактичного злиття. Можливо, ваше рішення - це варіант, який ви справді шукаєте.

Не зовсім зрозуміло, який саме бажаний результат, тому існує певна плутанина щодо «правильного» способу його виконання у відповідях та коментарях. Я намагаюся дати огляд і побачити наступні три варіанти:

Спробуйте об'єднати та використовувати B для конфліктів

Це не "їхня версія для git merge -s ours", а "їхня версія для git merge -X ours" (що скорочено git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

Це те, що, наприклад , відповідає відповідь Алана В. Сміта .

Використовуйте вміст лише з B

Це створює комісію для злиття для обох гілок, але відхиляє всі зміни branchAта зберігає лише вміст branchB.

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

Зауважимо, що злиття, яке здійснює перший батьків, зараз - це те, що є branchBлише другий branchA. Це, наприклад , відповідь Гандальф458 .

Використовуйте вміст лише з B та дотримуйтесь правильного батьківського порядку

Це справжня "їхня версія для git merge -s ours". Він має той самий зміст, що і у варіанті раніше (тобто лише в тому, що є з branchB), але порядок батьків правильний, тобто перший з батьків походить, branchAа другий з branchB.

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

Це робить відповідь Пола Пладійса (не вимагаючи тимчасової гілки).

З цього часу я використовував відповідь від Павла Пладійса. Я з'ясував, ви можете зробити "нормальне" злиття, виникають конфлікти, так що і ви

git checkout --theirs <file>

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

git merge <branch> -s theirs

У будь-якому випадку, зусиль більше, ніж було б із стратегією злиття! (Це було протестовано з git версія 1.8.0)

Я вирішив свою проблему за допомогою

git checkout -m old
git checkout -b new B
git merge -s ours old

Під час об'єднання гілки теми "B" в "A" за допомогою git merge я отримую деякі конфлікти. Я> знаю, всі конфлікти можна вирішити за допомогою версії в "В".

Мені відомо про злиття git - наше. Але я хочу щось подібне до git merge> -s їх.

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

Робіть саме те, що ви хочете зробити, за винятком того, як спочатку з’єднати одну гілку в іншу. Я просто це зробив, і це чудово спрацювало.

git checkout Branch
git merge master -s ours

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

git checkout master
git merge Branch

Якщо ви перебуваєте у відділенні A, зробіть:

git merge -s recursive -X theirs B

Тестовано на git версії 1.7.8

Дійсно правильно зробити злиття, яке бере лише вхід з тієї гілки, яку ви зливаєте, ви можете зробити

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

У будь-якому мені відомому сценарії не буде конфліктів, вам не доведеться робити додаткові гілки, і це діє як звичайна комісія злиття.

Однак це не грає з підмодулями.

Чому його не існує?

Хоча я в " git команді для створення однієї гілки як іншої " згадую, як імітувати git merge -s theirs, зауважте, що Git 2.15 (Q4 2017) тепер зрозуміліший:

Документація на -X<option>об'єднання " " для об'єднань була введена в оману, щоб припустити, що -s theirsіснує " ", що не так.

Див. Комісію c25d98b (25 вересня 2017 р.) Від Junio ​​C Hamano ( gitster) .
^{(Об’єднав Хуніо С Хамано - gitster- у комітеті 4da3e23 , 28 вересня 2017 р.)}

стратегії злиття: уникайте того, що " -s theirs" існує

Опис -Xoursваріанту злиття має круглі дужки, які повідомляють читачам, що він дуже відрізняється від -s ours, що є правильним, але опис, -Xtheirsякий слідує за ним, недбало говорить, що "це протилежне ours", створюючи помилкове враження, що читачам також потрібно щоб попередити, що він сильно відрізняється від того -s theirs, що насправді навіть не існує.

-Xtheirs- це варіант стратегії, застосований до рекурсивної стратегії. Це означає, що рекурсивна стратегія все одно зливатиме все, що тільки може, і повернеться до theirsлогіки лише у випадку конфліктів.

Ця дискусія щодо доцільності theirsстратегії злиття чи ні, була повернута нещодавно в цій темі вересня 2017 року .
Він визнає більш старі теми (2008)

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

Він згадує псевдонім:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

Ярослав Гальченко знову намагається виступати за цю стратегію, але Хуніо К. Хамано додає :

Причина, чому наша і їхня не симетричні, полягає в тому, що ти - це ти, а не ти - - контроль і право власності на нашу історію та їх історію не симетричні.

Після того, як ви вирішите, що їх історія є основною лінією, ви краще хочете ставитися до своєї лінії розвитку як до бічної гілки та здійснити злиття в цьому напрямку, тобто перший батьківський результат результату злиття є зобов’язанням щодо їх історії, а другий батьків - останній поганий з вашої історії. Отже, ви в кінцевому підсумку використовуватимете "checkout their-history && merge -s ours your-history " ", щоб зберегти розумність першого батьківства.

І в цей момент використання " -s ours" вже не є способом вирішення нестачі " -s theirs".
Це належна частина бажаної семантики, тобто з погляду збереженої канонічної лінії історії, ви хочете зберегти те, що вона зробила, зводячи нанівець те, що зробив інший рядок історії .

Хуніо додає, як коментує Майк Бітон :

git merge -s ours <their-ref>фактично говорить, що "маркування комісій, зроблених <their-ref>на їхній гілці, як зобов'язання постійно ігноруватися";
і це має значення, тому що, якщо згодом ви з’єднаєтесь із пізнішими станами їхньої галузі, їх більш пізні зміни будуть внесені без ігнорованих змін .

Дивіться широко цитовану відповідь Хуніо Хамано : якщо ви збираєтесь відмовитись від скоєного вмісту, просто відмовтеся від комітетів або будь-яким чином не відхиляйте його від основної історії. Чому в майбутньому турбувати всіх, хто читає, виконувати повідомлення з комітетів, які нічого запропонувати?

Але іноді існують адміністративні вимоги чи, можливо, якась інша причина. У тих ситуаціях, коли вам дійсно потрібно записати комісії, які нічого не сприяють, вам потрібно:

(ред .: wow, чи вдалося мені помилитися раніше. Це працює.)

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

У цьому використовується команда читання дерева git сантехніка, але дозволяє скоротити загальний робочий процес.

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Це об'єднає ваш newBranch у існуючий baseBranch

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Я думаю, що ти насправді хочеш:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

Це здається незграбним, але це має працювати. Єдине, що мені дуже не подобається в цьому рішенні, - це історія git, яка буде заплутаною ... Але принаймні історія буде повністю збережена і вам не потрібно буде робити щось особливе для видалених файлів.

Еквівалент (який зберігає батьківський порядок) "git merge -sss their branchB"

Перед об'єднанням:

!!! Переконайтесь, що ви в чистому стані !!!

Зробіть злиття:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

Що ми зробили? Ми створили новий комітет, який є двома батьками, нашими та їхніми, а також мережею комітету є відділенняB - їхнє

Після злиття:

Точніше:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Таку відповідь дав Пол Пладійс. Я просто взяв його команди і зробив гіт-псевдонім для зручності.

Відредагуйте .gitconfig та додайте наступне:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

Тоді ви можете "git merge -s njihovo A", запустивши:

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Мені нещодавно потрібно було зробити це для двох окремих сховищ, які мають спільну історію. Я почав з:

• Org/repository1 master
• Org/repository2 master

Я хотів, щоб усі зміни repository2 masterбули застосовані repository1 master, приймаючи всі зміни, які буде внесено у сховище2. З точки зору git, це має бути стратегія під назвою, -s theirsАЛЕ її немає. Будьте обережні, тому що -X theirsназваний так, як це було б те, що ви хочете, але це НЕ те саме (це навіть написано на сторінці man).

Я вирішив це, щоб піти repository2і створити нове відділення repo1-merge. У цій гілці я побіг, git pull git@gitlab.com:Org/repository1 -s oursі це добре зливається без проблем. Потім натискаю на пульт.

Потім я повертаюся до repository1та роблю нову гілку repo2-merge. У цій гілці я працюю, git pull git@gitlab.com:Org/repository2 repo1-mergeяка завершиться питаннями.

Нарешті, вам потрібно буде або надіслати запит на об'єднання, repository1щоб зробити його новим господарем, або просто зберегти його як гілку.

Простий та інтуїтивний (на мою думку) двоступеневий спосіб це зробити

git checkout branchB .
git commit -m "Picked up the content from branchB"

слідом за ним

git merge -s ours branchB

(що позначає дві гілки як об'єднані)

Єдиним недоліком є ​​те, що він не вилучає файли, які були видалені в branchB з вашої поточної гілки. Проста різниця між цими двома гілками згодом покаже, чи є такі файли.

Цей підхід також дає зрозуміти з журналу ревізії після цього, що було зроблено - і що було призначено.