880

多くの競合が発生する可能性があるリモート ブランチにマージしています。競合があるかどうかはどうすればわかりますか?

--dry-runonのようなものは見当たりませんgit-merge。

4

20 に答える 20

989

前述のように、--no-commitフラグを渡しますが、早送りコミットを避けるために--no-ff、次のように も渡します。

$ git merge --no-commit --no-ff $BRANCH

段階的な変更を調べるには:

$ git diff --cached

また、早送りマージであっても、マージを元に戻すことができます。

$ git merge --abort
于 2009-02-01T19:57:26.980 に答える
273

リポジトリとそのリモートの間の競合を自動的に検出するメソッドを実装する必要がありました。このソリューションはメモリ内でマージを行うため、インデックスにも作業ツリーにも触れません。これが、この問題を解決できる最も安全な方法だと思います。仕組みは次のとおりです。

  1. リモートをリポジトリにフェッチします。例えば： git fetch origin master
  2. git merge-base を実行します。git merge-base FETCH_HEAD master
  3. git merge-tree を実行しますgit merge-tree mergebase master FETCH_HEAD( mergebaseは、前の手順で merge-base が出力した 16 進数の ID です)。

ここで、リモート マスターをローカル マスターとマージしたいが、任意のブランチを使用できるとします。git merge-treeメモリ内でマージを実行し、結果を標準出力に出力します。パターンの grep<<または>>. または、出力をファイルに出力して確認することもできます。'changed in both' で始まる行が見つかった場合は、競合が発生している可能性があります。

于 2011-06-08T19:04:09.967 に答える
114

実際にマージを試みる前に、自分がどれだけの問題を抱えているかを知りたいだけだと思います...そして、マージが失敗した後に最後のコミットにリセットするのは比較的簡単なので、それが起こっても驚かないでしょう意図したアプローチです。

とはいえ、作業ツリー内の既存のファイルに本当に手を加えたくない場合は、パッチを作成してターゲット ブランチに対してテストすることができます。これには、どのファイルにどのような変更が加えられたかを正確に表示できるという利点もあります。パッチ ファイルをテキスト エディタで開くだけです。

git checkout -b mycrazybranch
[change some stuff...]
git add .
git commit -m "changed some stuff"
git format-patch master --stdout > crazy.patch
git checkout master
git apply crazy.patch --check
[all good! cleanup...]
rm crazy.patch

ご覧のとおり、これによりパッチ ファイルが作成されます。次に --check でテストし、エラーがないかどうかを確認してから、パッチ ファイルを削除します。

于 2011-06-14T06:29:18.293 に答える
83

git merge --abort競合があることを確認した後に行うことができます。

于 2011-06-13T20:30:44.293 に答える
70

既存の回答の要約として、マージの競合があるかどうかを確認する方法が 2 つあります。

git format-patch $(git merge-base branch1 branch2)..branch2 --stdout | git apply --3way --check -

branch1上記のコマンドを実行すると、現在のブランチが必要になることに注意してください

別の方法：

git merge --no-commit branch2
# check the return code here
git merge --abort
于 2012-09-10T04:13:34.077 に答える
61

これに対する私の単純なブルートフォースソリューションは次のとおりです。

  1. 「プレマスター」ブランチを作成します（もちろんマスターから）

  2. 必要なものをすべてこのプレマスターにマージします。
    次に、マスターに触れずにマージがどのように行われたかを確認できます。

    • プレマスターをマスターにマージするまたは
    • リリースしたいすべてのブランチをマスターにマージします

とにかく、私は@orange80のアドバイスに従います。

于 2011-05-16T16:29:30.183 に答える
49

git を使用してマージを元に戻すのはとても簡単なので、予行演習についても心配する必要はありません。

$ git pull $REMOTE $BRANCH
# uh oh, that wasn't right
$ git reset --hard ORIG_HEAD
# all is right with the world

編集：以下のコメントに記載されているように、作業ディレクトリまたはステージング領域に変更がある場合は、おそらく上記を実行する前にそれらを隠しておきたいでしょう（そうしないと、git reset上記の後に消えます）

于 2009-02-01T21:24:46.180 に答える
29

現在のブランチをリモートブランチと比較するだけで、プル/マージを実行したときに何が変わるかがわかります。

#see diff between current master and remote branch
git diff master origin/master
于 2010-12-10T03:31:39.977 に答える
24

正確にはそうではありません。ただし、-no-commitオプションを使用できるため、マージ後に結果が自動的にコミットされることはありません。このようにして、コミットツリーをいじることなく、マージを検査し、必要に応じて元に戻すことができます。

于 2011-06-13T20:15:46.867 に答える
23

そのためにrequest-pull git コマンドを使用します。これにより、マージ時に発生するすべての変更を確認できますが、ローカルまたはリモートのリポジトリで何もする必要はありません。

たとえば、「feature-x」という名前のブランチを master ブランチにマージしたいとします。

git request-pull master origin feature-x

何が起こるかの要約が表示されます（何もしません）：

The following changes since commit fc01dde318:
    Layout updates (2015-06-25 11:00:47 +0200)
are available in the git repository at:
    http://fakeurl.com/myrepo.git/ feature-x
for you to fetch changes up to 841d3b41ad:
----------------------------------------------------------------
john (2):
    Adding some layout
    Refactoring
ioserver.js            |   8 +++---
package.json           |   7 +++++-
server.js              |   4 +--
layout/ldkdsd.js       | 277 +++++++++++++++++++++++++++++++++++++
4 files changed, 289 insertions(+), 7 deletions(-)
create mode 100644 layout/ldkdsd.js

パラメータを追加する-pと、変更されたすべてのファイルに対して git diff を実行した場合とまったく同じように、完全なパッチ テキストも取得されます。

于 2015-06-26T10:24:45.997 に答える
9

git log を使用して、機能ブランチで master ブランチから何が変更されたかを確認します

git log does_this_branch..contain_this_branch_changes

例 - master にマージされた/マージされていない機能ブランチにあるコミットを確認するには:

git log master..feature_branch
于 2013-07-02T23:20:07.897 に答える
3

B から A に早送りしたい場合は、git log B..A が何も表示しないことを確認する必要があります。つまり、A には B にないものは何もありません。しかし、B..A に何かがあったとしても、競合することなくマージできる可能性があるため、上記は 2 つのことを示しています。

于 2011-02-06T18:01:12.453 に答える
1

これは理論的にはトピックから外れていることはわかっていますが、実際には、Google 検索からここにたどり着いた人々にとっては非常にトピックに合っています。

疑わしい場合は、いつでも Github インターフェースを使用してプルリクエストを作成し、それがクリーンなマージが可能であることを示しているかどうかを確認できます。

于 2021-02-22T13:32:33.477 に答える
-1

作業コピーの一時コピーを作成し、それにマージして、2 つを比較します。

于 2015-01-05T17:23:27.877 に答える