git-merge --dry-runオプションはありますか？

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

のようなものが表示さ--dry-runれませんgit-merge。

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

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

段階的な変更を確認するには：

$ git diff --cached

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

$ git merge --abort

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

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'で始まる行を見つけた場合、おそらく競合が発生しています。

これに対する私の単純な総当たりの解決策は次のとおりです。

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

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

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

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

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

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

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

私はこれを行うためのエイリアスを作成し、魅力のように機能します、私はこれを行います：

 git config --global alias.mergetest '!f(){ git merge --no-commit --no-ff "$1"; git merge --abort; echo "Merge aborted"; };f '

今すぐ電話します

git mergetest <branchname>

競合があるかどうかを確認する。

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

#see diff between current master and remote branch
git diff master origin/master

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

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

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を実行した場合とまったく同じように、完全なパッチテキストも取得されます。

誰もまだパッチの使用を提案していないことに驚いています。

からyour_branchへのマージをテストしたいとmasterします（私はあなたがmasterチェックアウトしたと仮定しています）：

$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch

これでうまくいくはずです。

次のようなエラーが発生した場合

error: patch failed: test.txt:1
error: test.txt: patch does not apply

つまり、パッチは成功せず、マージによって競合が発生します。出力がないことは、パッチがクリーンであり、ブランチを簡単にマージできることを意味します

これによって実際に作業ツリーが変更されるわけではないことに注意してください（もちろん、パッチファイルの作成は除きますが、後で安全に削除できます）。git-applyのドキュメントから：

--check
    Instead of applying the patch, see if the patch is applicable to the
    current working tree and/or the index file and detects errors. Turns
    off "apply".

私よりもgitの方が賢い、または経験が豊富な人への注意：ここで私が間違っていて、このメソッドが通常のマージとは異なる動作をする場合は、私に知らせてください。この質問が存在していた8年以上前に、この一見明白な解決策をだれも提案しなかったことは奇妙に思われます。

これは興味深いかもしれません：ドキュメントから：

複雑な競合を引き起こしたマージを試みてやり直したい場合は、git merge --abortを使用して回復できます。

しかし、それを素朴な（しかし遅い）方法で行うこともできます。

rm -Rf /tmp/repository
cp -r repository /tmp/
cd /tmp/repository
git merge ...
...if successful, do the real merge. :)

（注：/ tmpにクローンを作成するだけでは機能しません。コミットされていない変更が競合しないようにするには、コピーが必要です）。

これは古い質問であることは承知していますが、Google検索で初めて表示されます。

Gitはマージ時に--ff-onlyオプションを導入しました。

送信元：http : //git-scm.com/docs/git-merge

---

--ffのみ

現在のHEADが既に最新であるか、マージが早送りとして解決できる場合を除き、マージを拒否してゼロ以外のステータスで終了します。

これを行うと、マージと早送りが試行されますが、それができない場合は中止され、早送りを実行できなかったが、作業中のブランチはそのままになります。早送りできる場合は、作業中のブランチでマージを実行します。このオプションは、でも使用できますgit pull。したがって、次のことができます。

git pull --ff-only origin branchA #See if you can pull down and merge branchA

git merge --ff-only branchA branchB #See if you can merge branchA into branchB

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

git log does_this_branch..contain_this_branch_changes

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

git log master..feature_branch

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

私の解決策は、後方にマージすることです。

ブランチをリモートの「ターゲット」ブランチにマージする代わりに、そのブランチを自分のブランチにマージします。

git checkout my-branch
git merge origin/target-branch

競合があるかどうかを確認し、解決方法を計画できます。

その後、gitを使用してマージを中止するかmerge --abort、（競合が発生せず、マージが発生した場合）を介して以前のコミットにロールバックできますgit reset --hard HEAD~1

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