「彼らの」バージョンの「git merge -s ours」はありますか？

を使用してトピックブランチ「B」を「A」にマージするとgit merge、いくつかの競合が発生します。「B」のバージョンを使用すると、すべての競合を解決できることを知っています。

私は承知していgit merge -s oursます。しかし、私が欲しいのはのようなものですgit merge -s theirs。

なぜそれが存在しないのですか？既存のgitコマンドとマージして競合した後、どうすれば同じ結果を得ることができますか？（git checkoutBからのすべてのマージされていないファイル）

更新：ブランチ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

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を引数として使用してスクリプトにラップします。

このソリューションでは、期待どおりに、マージコミットの最初と2番目の親が保持されますgit merge -s theirs branchB。

古いバージョンのgitでは、「それら」のマージ戦略を使用できました。

git pull --strategy=theirs remote_branch

しかし、このメッセージで説明されているように、このメッセージは浜野純生（Gitメンテナー）によって削除されました。リンクに記載されているように、代わりに次のようにします。

git fetch origin
git reset --hard origin

ただし、これは実際のマージとは異なることに注意してください。あなたのソリューションはおそらくあなたが本当に探しているオプションです。

望ましい結果が完全に明確ではないため、回答とコメントで「正しい」方法を実行することについて混乱が生じます。概要を説明し、次の3つのオプションを確認します。

マージしてみて、競合に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

これは、たとえばAlan W. Smithの回答が行うことです。

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、2番目はから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

これはPaul Pladijsの答えです（一時的なブランチを必要としない）。

私は今からポール・プラディスの答えを使いました。私が知った、あなたは「通常の」マージを行うことができ、競合が発生するので、

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

git mergeを使用してトピックブランチ「B」を「A」にマージすると、いくつかの競合が発生します。>すべての競合は「B」のバージョンを使用して解決できることを知っています。

私はgit merge -s oursを知っています。しかし、私が欲しいのはgit merge> -s theirのようなものです。

私はあなたがマスターからブランチを作成し、今マスターにマージしてマスターの古いものを上書きしたいと仮定しています。これは、この投稿に出くわしたときにまさにやりたかったことです。

最初に1つのブランチを他のブランチにマージすることを除いて、それがしたいことを正確に実行してください。私はこれをやっただけで、うまくいきました。

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（2017年第4四半期）がより明確になっていることに注意してください。

-X<option>マージ用の ' ' のドキュメントは、「-s theirs」が存在することを示唆するように誤解を招くように書かれていましたが、そうではありません。

Junio C Hamano（）によるcommit c25d98b（2017年9月25日）を参照してください。^{（による合併Junio C浜野- -で4da3e23コミット、2017年9月28日に）}gitster
gitster

マージ戦略：「-s theirs」が存在することを示唆することを避けます

説明-Xoursマージオプションは、それは非常に異なっていることを読者に伝え括弧付きのノート持って-s ours正しい、しかし、の説明-Xtheirsそれはそれは不用意に「これは反対であると言い、次のours読者にも必要という誤った印象を与え、」とは非常に異なり-s theirs、実際には存在しないことを警告されます。

-Xtheirsある戦略オプション再帰的戦略に適用されます。これは、再帰的な戦略でも可能な限りマージしtheirs、競合が発生した場合にのみ " "ロジックにフォールバックすることを意味します。

theirsマージ戦略の妥当性に関するこの議論は、2017年9月のこのスレッドで最近取り上げられました。古い（2008）スレッドを
認識します

簡単に言うと、前の議論は「-s theirs間違ったワークフローを助長するので、「」は欲しくない」と要約できます。

それはエイリアスについて言及しています：

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

ヤロスラフ・ハルチェンコはその戦略をもう一度提唱しようとしますが、ジュニオ・C・ハマノは次のように付け加えます：

私たちと彼らの関係が対称的ではない理由は、あなたがあなたであり彼らではないからです。私たちの歴史とその歴史の管理と所有権は対称的ではありません。

それらの履歴がメインラインであると判断したら、開発ラインをサイドブランチとして扱い、その方向にマージする必要があります。つまり、結果のマージの最初の親は、それらの履歴に対するコミットであり、2番目は親はあなたの歴史の最後の悪い人です。そのcheckout their-history && merge -s ours your-historyため、「」を使用して、最初の親子関係を賢明に保つことになります。

その時点で、「-s ours」の使用は「」の欠如に対する回避策ではなくなりました-s theirs。
これは、目的のセマンティクスの適切な部分です。つまり、生き残った正規履歴行の観点から、それが行ったことを保持し、他の履歴行が行ったことを無効にしたいとします。

マイク・ビートンがコメントしたように、ジュニオは付け加えた。

git merge -s ours <their-ref>効果的に「<their-ref>永続的に無視されるコミットとして、ブランチで行われたコミットにマークを付ける」;
そして、これが重要になるのは、後でブランチのより後の状態からマージすると、無視された変更が反映されることなく、その後の変更が反映されるからです。

浜野純夫の広く引用されている答えを参照してください。コミットされたコンテンツを破棄する場合は、コミットを破棄するか、いずれにしても、メインの履歴から除外してください。将来的に、提供するものがないコミットからのコミットメッセージを誰もが気にしないのはなぜですか？

ただし、管理上の要件やその他の理由がある場合もあります。何も貢献しないコミットを実際に記録する必要がある状況では、次のようにします。

（編集：わあ、なんとか前にこれを間違えたことがあります。これは機能します。）

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

これはgit plumbingコマンドのread-treeを使用していますが、全体的なワークフローが短くなっています。

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

我々のしたこと ？私たちは2人の親が私たちと彼らのものであり、コミットの内容がブランチBである新しいコミットを作成しました-彼らのもの

マージ後：

より正確に：

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

この答えはPaul Pladijsによって与えられました。私は彼のコマンドを受け取り、便宜上gitエイリアスを作成しました。

.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 theirs A」を実行できます。

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

最近、共通の履歴を共有する2つの別々のリポジトリに対してこれを行う必要がありました。私は始めました：

• Org/repository1 master
• Org/repository2 master

からのすべての変更repository2 masterをに適用してrepository1 master、repository2が行うすべての変更を受け入れたいと思っていました。gitの用語では、これは-s theirs BUTと呼ばれる戦略ですが、存在しません。ので、注意してください-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新しいマスターにするためにマージ要求を発行するか、単にブランチとして保持する必要があります。

シンプルで直感的な（私の意見では）2ステップの方法は

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

に続く

git merge -s ours branchB

（2つのブランチをマージ済みとしてマークします）

唯一の欠点は、branchBで削除されたファイルが現在のブランチから削除されないことです。その後、2つのブランチ間の単純な差分は、そのようなファイルがあるかどうかを示します。

このアプローチは、何が行われたのか、何が意図されていたのかを後で改訂ログから明らかにします。