Есть ли «их» версия «git merge -s ours»?

Я решил свою проблему с помощью

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

Более старые версии git позволяли использовать «их» стратегию слияния:

git pull --strategy=theirs remote_branch

Но с тех пор это было удалено, как объясняет в этом сообщении Хунио Хамано (сопровождающий Git). Как указано в ссылке, вместо этого вы должны сделать это:

git fetch origin
git reset --hard origin

Однако помните, что это отличается от фактического слияния. Вероятно, ваше решение - это тот вариант, который вы действительно ищете.

Добавьте опцию -X к theirs. Например:

git checkout branchA
git merge -X theirs branchB

Все сольется желаемым образом.

Единственное, что я видел, вызывает проблемы, это если файлы были удалены из ветки B. Они проявляются как конфликты, если удаление выполнялось не с помощью git.

Исправить легко. Просто запустите git rm с именем всех удаленных файлов:

git rm {DELETED-FILE-NAME}

После этого -X theirs должен работать должным образом.

Конечно, фактическое удаление с помощью команды git rm в первую очередь предотвратит возникновение конфликта.

Примечание: также существует опция более длинной формы.

Чтобы использовать его, замените:

-X theirs

с:

--strategy-option=theirs

Возможное и проверенное решение для слияния BranchB с нашим проверенным branchA:

# 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.

Если вы находитесь в ветке A, сделайте:

git merge -s recursive -X theirs B

Проверено на git версии 1.7.8

С этого момента я использовал ответ Пола Пладийса. Я выяснил, можно сделать "нормальное" слияние, возникают конфликты, так что вы делаете

git checkout --theirs <file>

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

git merge <branch> -s theirs

В любом случае, усилий больше, чем было бы со стратегией слияния! (Это было протестировано с версией git 1.8.0)

Это объединит вашу новую ветку в существующую базовую ветку

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 update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

When merging topic branch "B" in "A" using git merge, I get some conflicts. I >know all the conflicts can be solved using the version in "B".

I am aware of git merge -s ours. But what I want is something like git merge >-s their.

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

Делайте именно то, что вы хотите, за исключением того, что сначала слейте одну ветвь с другой. Я только что сделал это, и это отлично сработало.

git checkout Branch
git merge master -s ours

Затем выполните проверку мастера и объедините в нем свою ветку (теперь все пройдет гладко):

git checkout master
git merge Branch

Чтобы действительно правильно выполнить слияние, которое принимает ввод Только из ветки, которую вы объединяете, вы можете сделать

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

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

git commit --amend

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

Однако это не очень хорошо работает с подмодулями.

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

Попробуйте объединить и используйте 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. Вот что, например, Gandalf458 ответ делает.

Используйте контент только из 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, но в целом рабочий процесс сокращается.

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>

Я думаю, что на самом деле вам нужно:

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

Это кажется неуклюжим, но должно работать. Единственное, что мне действительно не нравится в этом решении, так это то, что история git будет сбивать с толку ... Но, по крайней мере, история будет полностью сохранена, и вам не нужно будет делать что-то особенное для удаленных файлов.

Совсем недавно мне понадобилось сделать это для двух отдельных репозиториев, имеющих общую историю. Я начал с:

• Org/repository1 master
• Org/repository2 master

Я хотел, чтобы все изменения из repository2 master были применены к repository1 master, приняв все изменения, которые внесет repository2. С точки зрения git, эта должен является стратегией -s theirs, НО ее не существует. Будьте осторожны, потому что -X theirs назван так, как вы хотите, но это то же самое НЕТ (это даже сказано на странице руководства).

Я решил это сделать, перейдя на repository2 и создав новую ветку repo1-merge. В этой ветке я запустил git pull [email protected]:Org/repository1 -s ours, и он отлично сливается без проблем. Затем я нажимаю на пульт.

Потом возвращаюсь к repository1 и делаю новую ветку repo2-merge. В этой ветке я запускаю git pull [email protected]:Org/repository2 repo1-merge, который решит проблемы.

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

Why doesn't it exist?

Хотя я упоминал в «команда git, чтобы сделать одну ветку похожей на другую», как моделировать git merge -s theirs, обратите внимание, что Git 2.15 (Q4 2017) теперь более понятен:

The documentation for '-X<option>' for merges was misleadingly written to suggest that "-s theirs" exists, which is not the case.

См. совершить c25d98b (25 сентября 2017 г.), автор: Junio ​​C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 4da3e23, 28 Sep 2017)}

merge-strategies: avoid implying that "-s theirs" exists

The description of -Xours merge option has a parenthetical note that tells the readers that it is very different from -s ours, which is correct, but the description of -Xtheirs that follows it carelessly says "this is the opposite of ours", giving a false impression that the readers also need to be warned that it is very different from -s theirs, which in reality does not even exist.

-Xtheirs - это вариант стратегии, применяемый к рекурсивной стратегии. Это означает, что рекурсивная стратегия по-прежнему объединяет все, что может, и будет возвращаться к логике «theirs» только в случае конфликтов.

Эти дебаты относительно уместности стратегии слияния theirs были недавно возобновлены в этой ветке за сентябрь 2017 г..
Подтверждает старые (2008) темы

In short, the previous discussion can be summarized to "we don't want '-s theirs' as it encourages the wrong workflow".

В нем упоминается псевдоним:

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

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

The reason why ours and theirs are not symmetric is because you are you and not them---the control and ownership of our history and their history is not symmetric.

Once you decide that their history is the mainline, you'd rather want to treat your line of development as a side branch and make a merge in that direction, i.e. the first parent of the resulting merge is a commit on their history and the second parent is the last bad one of your history. So you would end up using "checkout their-history && merge -s ours your-history" to keep the first-parenthood sensible.

And at that point, use of "-s ours" is no longer a workaround for lack of "-s theirs".
It is a proper part of the desired semantics, i.e. from the point of view of the surviving canonical history line, you want to preserve what it did, nullifying what the other line of history did.

Джунио добавляет, как прокомментировал Майк Битон:

git merge -s ours <their-ref> effectively says 'mark commits made up to <their-ref> on their branch as commits to be permanently ignored';
and this matters because, if you subsequently merge from later states of their branch, their later changes will be brought in without the ignored changes ever being brought in.

Эквивалент (который сохраняет родительский порядок) для 'git merge -s theirs branchB'

Перед объединением:

!!! Убедитесь, что вы в чистом состоянии !!!

Сделайте слияние:

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

Что мы сделали ? Мы создали новый коммит, у которого два родителя - наш и их, и продолжение коммита - BranchB - их

После слияния:

Точнее:

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

Простой и интуитивно понятный (на мой взгляд) двухэтапный способ сделать это:

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

с последующим

git merge -s ours branchB

(который отмечает две ветви как объединенные)

Единственным недостатком является то, что он не удаляет файлы, которые были удалены в ветке B, из вашей текущей ветки. Простое различие между двумя ветвями впоследствии покажет, есть ли такие файлы.

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

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

Отредактируйте свой .gitconfig и добавьте следующее:

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

Затем вы можете выполнить команду git merge -s theirs A, выполнив:

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