Is there a git-merge --dry-run option?

问题:

I'm merging in a remote branch that may have a lot of conflicts. How can I tell if it will have conflicts or not?

I don't see anything like a --dry-run on git-merge.

回答1:

As noted previously, pass in the --no-commit flag, but to avoid a fast-forward commit, also pass in --no-ff, like so:

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

To examine the staged changes:

$ git diff --cached

And you can undo the merge, even if it is a fast-forward merge:

$ git merge --abort

回答2:

I just had to implement a method that automatically finds conflicts between a repository and its remote. This solution does the merge in memory so it won't touch the index, nor the working tree. I think this is the safest possible way you can solve this problem. Here's how it works:

1. Fetch the remote to your repository. For example: git fetch origin master
2. Run git merge-base: git merge-base FETCH_HEAD master
3. Run git merge-tree: git merge-tree mergebase master FETCH_HEAD (mergebase is the hexadecimal id that merge-base printed in the previous step)

Now suppose that you want to merge the remote master with your local master, but you can use any branches. git merge-tree will execute the merge in memory and print the result to the standard output. Grep for the pattern or >>. Or you can print the output to a file and check that. If you find a line starting with 'changed in both' then most probably there will be a conflict.

回答3:

Undoing a merge with git is so easy you shouldn't even worry about the dry run:

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

EDIT: As noted in the comments below, if you have changes in your working directory or staging area you'll probably want to stash them before doing the above (otherwise they will disappear following the git reset above)

回答4:

My brute-force simple solution to this is:

1: create a pre-master branch (from master of course)
2: merge all the things you want to do to this pre-master
then you can see how the merging happened without touching master then.
3a: merge pre-master into master or
3b: merge all wannabe-released branches into master

Anyway I would follow @orange80 advise.

回答5:

I made an alias for doing this and works like a charm, I do this:

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

Now I just call

git mergetest 

To find out if there are any conflicts.

回答6:

Just diff your current branch against the remote branch, this will tell you what is going to change when you do a pull/merge.

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

回答7:

I use the request-pull git command to do so. It allows you to see every change that would happen when merging, but without doing anything on your local or remote repositories.

For instance, imagine you want to merge a branch named "feature-x" into your master branch

git request-pull master origin feature-x

will show you a summary of what would happen (without doing anything):

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

If you add the -pparameter, you will also get the full patch text, exactly like if you were doing a git diff on every changed file.

回答8:

This might be interesting: From the documentation:

If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort.

But you could also do it the naive (but slow) way:

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

(Note: It won't work just cloning to /tmp, you'd need a copy, in order to be sure that uncommitted changes will not conflict).

回答9:

I am aware that this is an old question, but it is the first to appear on a Google search.

Git introduced a --ff-only option when merging.

From: http://git-scm.com/docs/git-merge

---

--ff-only

Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.

Doing this will attempt to merge and fast-forward, and if it can't it aborts and prompts you that the fast-forward could not be performed, but leaves your working branch untouched. If it can fast-forward, then it will perform the merge on your working branch. This option is also available on git pull. Thus, you could do the following:

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

回答10:

I'm surprised nobody has suggested using patches yet.

Say you'd like to test a merge from your_branch into master (I'm assuming you have master checked out):

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

That should do the trick.

If you get errors like

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

that means that the patch wasn't successful and a merge would produce conflicts. No output means the patch is clean and you'd be able to easily merge the branch

---

Note that this will not actually change your working tree (aside from creating the patch file of course, but you can safely delete that afterwards). From the git-apply documentation:

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

---

Note to anyone who is smarter/more experienced with git than me: please do let me know if I'm wrong here and this method does show different behaviour than a regular merge. It seems strange that in the 8+ years that this question has existed noone would suggest this seemingly obvious solution.

回答11:

I use git log to see what has changed on a feature branch from master branch

git log does_this_branch..contain_this_branch_changes

e.g. - to see what commits are in a feature branch that has/not been merged to master:

git log master..feature_branch

回答12:

If you want to fast forward from B to A, then you must make sure that git log B..A shows you nothing, i.e. A has nothing that B doesn't have. But even if B..A has something, you might still be able to merge without conflicts, so the above shows two things: that there will be a fast-forward, and thus you won't get a conflict.

回答13:

Make a temporary copy of your working copy, then merge into that, and diff the two.

转载请标明出处:Is there a git-merge --dry-run option?

文章来源: Is there a git-merge --dry-run option?