特定のファイル(「ours」、「mine」、「theirs」)のGitマージ戦略を選択します


207

私はリベースの最中ですgit pull --rebase。マージの競合があるファイルがいくつかあります。特定のファイルの「自分の」変更または「自分の」変更をどのように受け入れることができますか?

$ git status
# Not currently on any branch.
# You are currently rebasing.
#   (fix conflicts and then run "git rebase --continue")
#   (use "git rebase --skip" to skip this patch)
#   (use "git rebase --abort" to check out the original branch)
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:  CorrectlyMergedFile
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add <file>..." to mark resolution)
#
#       both modified: FileWhereIWantToAcceptTheirChanges
#       both modified: FileWhereIWantToAcceptMyChanges

通常、私はファイルまたはマージツールを開き、手動ですべての「自分の」または「自分の」変更を受け入れます。ただし、便利なgitコマンドがないと思います。

また、どのファイルが競合にヒットしたか、あるいは競合が何であるかを確認した場合にのみ、各ファイルのマージ戦略を選択できることに注意してください。


@AbeVoelker私が問題を解決するとは思わない。特定のファイルのマージ戦略を選択したい。また、私がリベースしているときに使用するマージ戦略だけを知って、どのファイルが競合をヒットし、どのような競合があるかを確認することに注意してください。
Steven Wexler 2013年

この質問をより一般的なものに編集しました:stackoverflow.com/questions/278081/…。たぶん、この質問をその複製として閉じることができますか?それは適切ですか?

@TheShadowそれは私には理にかなっているようです。
Steven Wexler 2013年

バイナリファイルの解決に関する部分を削除したので、他の質問のタイトルを自分のやったことに変更することが適切かどうかはわかりませんでした。他の質問を以前のものに戻したので、この現在の質問はまだ価値を追加しています。

回答:


251

取得する競合ファイルごとに、次を指定できます

git checkout --ours -- <paths>
# or
git checkout --theirs -- <paths>

ドキュメントからgit checkout

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...

--ours
--theirs
インデックスからパスをチェックアウトするときは、マージされていないパスのステージ#2(ours)または#3(theirs)をチェックアウトします。

以前にマージが失敗したため、インデックスにはマージされていないエントリが含まれている可能性があります。デフォルトでは、そのようなエントリをインデックスからチェックアウトしようとすると、チェックアウト操作は失敗し、何もチェックアウトされません。を使用-fすると、これらのマージされていないエントリは無視されます。マージの特定の側のコンテンツは、--oursまたはを使用してインデックスからチェックアウトできます--theirs。を使用-mすると、作業ツリーファイルに加えた変更を破棄して、元の競合したマージ結果を再作成できます。


9
不明なままになっているすべてのファイルについて、それらを受け入れることは可能ですか?
aslakjo 2013

41
@aslakjo git rebase -s recursive -X <ours/theirs>またはgit merge -s recursive -X <ours/theirs>。リベースの場合、「ours」と「theirs」はマージ中のものとは逆になることに注意してください。おそらく、ファイル/シェルグロブも使用できますgit checkout --theirs -- *.txt

2
@Cupcake、どうもありがとうございました。リベースでの予期せぬ逆転はours/theirs私を夢中にさせました!! (リベースが実際にどのように機能するかについて考えているのは理にかなっていますが、まったく直感的ではありません。)
Dan Lenski '19

2
一般に、@ DanLenskiのリベースは、最初は人々が理解するのに非常にトリッキーなツールですが、それがどのように機能するかを理解すれば、あらゆる種類の非常に強力なことを行うことができます。

1
@VincentSels実際には、*文字をマスクする必要があります。そうしないと、シェルがそれを拡張しようとします。だからあなたの場合git checkout --outs -- "**/*.csproj"はあなたが意味することをします。同じことが、たとえばに当てはまりますgit lfs track "*.jpg"。CWDにいくつかのjpgファイルがあり、引用符がない場合は、これらだけが追跡されます。
eFloh

117

この質問には答えていますが、git rebaseとmergeの場合の「theirs」と「ours」の意味の例を示します。このリンクを参照してください

Git Rebase
theirsは、rebaseの場合、実際には現在のブランチです。したがって、以下のコマンドセットは、実際にはリモートブランチを介した現在のブランチの変更を受け入れています。

# see current branch
$ git branch
... 
* branch-a
# rebase preferring current branch changes during conflicts
$ git rebase -X theirs branch-b

Gitのマージ
については、マージ、の意味theirsours逆転しています。したがって、マージ中に同じ効果を得るには、つまり、マージoursされるリモートブランチ()に対する現在のブランチの変更()を保持しますtheirs

# assuming branch-a is our current version
$ git merge -X ours branch-b  # <- ours: branch-a, theirs: branch-b

2
まあ、これは非常に重要な違いです!説明してくれてありがとう。
verboze

26

は、またはバージョンを選択することにより、ファイルを完全上書きすることgit checkout --ours|--theirsに注意してください。これは、実行したい場合とそうでない場合があります(反対側からの競合しない変更がある場合、それらは失われます)。theirsours

代わりに、ファイルに対して3者間マージを実行し、を使用して競合するハンクのみを解決し、競合しないハンクを両側から保持する場合は、に頼ることができます。この回答の詳細をご覧ください。--ours|--theirsgit merge-file


1
失われる「競合しない変更」について-これは、特定の行で競合しない変更が他の同じファイルにあるファイルのみを指しますか、または整列された履歴内のすべてのファイルからのすべての変更を指しますか?
ktamlyn

2
「競合しない変更」による@ktamlyn私は同じファイルの変更を意味しました。たとえばexample.txtoursバージョンには2つの変更されたハンク(パーツ)があり、1つは競合(theirsリビジョンでも変更)され、もう1つは競合されません。実行するとgit checkout --theirs example.txttheirsリビジョンでファイル全体を盲目的に読み取るだけで、競合のないdiffの部分が失われます。
jakub.g 2018年

1
ありがとう!これは、「同じファイルの変更」がこのコンテキストで最も理にかなっているにもかかわらず、私にとって必要な説明でした。
ktamlyn 2018年

これは受け入れられる答えであるはずですが、実際には答えはありませんが、他の提案されたソリューションの重要な問題を指摘しています。
tomasyany

1
競合する元のファイルに戻りたい場合は、を実行できますgit checkout --merge <path>
Andrew Keeton、
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.