CODEWITHSUNDEEP
gitmergemerge-conflict-resolution
gvgramazio
gvgramazio

Reputation: 1154

git merge: there is a way to operate on the files involved even if there isn't merge conflict?

A merge conflict happens if and only if two branches have a modification of the same line before a merge. However, even if a merge conflict doesn't happen, it could be that the result of a merge of two perfectly working branches doesn't work. There is a way to pre-merge two branches, working on the files that should result from the merge (maybe also add/delete/modify other ones) and then commit the merge result? I've tried but I have this possibility only when a merge conflict happens and only on the line of code involved. I'm sure that can be done in git (I cannot be the only one with this problem) but I don't know the sequence of commands to launch.

Upvotes: 2

Views: 60

Answers (3)

torek
torek

Reputation: 487725

(This should be a comment, but it's a bit long and needs some formatting.)

There are two answers at the time I write this:

  • git merge --no-commit, adjust the results (and git add as needed), and commit using git commit or git merge --continue; or
  • git merge, test and fix (and git add as needed), and use git commit --amend to shove the old merge commit out of the way, replacing it with a new-and-improved one.

Both will work. Note, however, that there's a school of thought that says you should never do either of these as it will be impossible to use an automated system to repeat the merge in the future. It's not clear to me which option those who subscribe to this rule prefer, as there are two:

  • Before merge, make a commit (or several commits) that prepare everything so that an automated merge succeeds and produces a valid result.
  • Or, after the automated merge that succeeds but produces an invalid result, make a subsequent commit that fixes it.

In either case, any "prepare" or "fix" commits, and any commits that don't work on their own, should probably have an explanatory log message. If it's the merge itself that doesn't work, note that in the merge commit's log message: replace the rather pointless merge branch <name> message with something like:

automatic but broken merge of branch <name>

This merge has the contents that Git produces on its own,
and exists so that someone who is repeating the work in the
future can do it automatically as well, and compare.  The
*next* commit contains the manual change that makes the
merge functional, so when bisecting, use the *next* commit,
not this one.

Of course, if you prefer the school of thought that says "don't make broken commits on purpose" you'll just merge-and-fix (with either --no-commit or --amend, whichever you prefer).

Upvotes: 2

Martin G
Martin G

Reputation: 18109

You can also first do the merge, then test it, fix problems and lastly git commit --amend your fixes to the merge commit before pushing it.

Upvotes: 1

Romain Valeri
Romain Valeri

Reputation: 21908

git merge --no-commit <branchName>

is intended for this very purpose (see doc).

(You don't need to do git merge --continue afterwards, just commit your work when the current state suits your needs. Without forgetting to add any modification you could have introduced after your non-committing merge)

Upvotes: 4

Related Questions