Git merge conflicts resolved and there are no changes to commit

Question

I have a 'featurex' branch extends from develop. When I make a pull request to develop I have conflicts. I'm trying to fix it on this lines:

1. git checkout featurex
2. git merge develop (and I have conflicts)
3. I fixed the conflicts (preserving my branch code)
4. I stage the resolutions of conflicts (and there are any change on stage)
5. I want to commit but there are not changes to commit

Maybe my proccess is wrong...

Answer 1

The answer is git merge --continue and then git push.

As in, you resolve the conflict, then you dont have anything to commit of course, so you just do a git merge --continue and it will make an empty commit.

Other answer said something about git rebase but I guess rebase is not an option if you've commited already to the remote branch, because you're then forced to rewrite history. So you're forced to use git push --force which is a bad pattern. Which I guess it's ok for whoever follows these dark force practices of the sith.

Answer 2

It sometimes happens that, while resolving merge conflicts, the final end result is "do not make any changes".

Consider, for instance, the following text file's lines:

Balls come in several colors.  Red is the most popular.

This is how the file appeared in some commit. Now you and your co-worker both obtained this commit and began working. Meanwhile, sales informed you that in fact, green is the most popular.

Your co-worker is British and did this:

Balls come in several colours.  Green is the most popular.

You did this:

Balls come in several colors.  Green is the most popular.

You both committed, but your co-worker's git push happened before your git push. You then got an error when you ran git push about the push being a non-fast-forward, so you obtained your co-worker's commit—which changes the spelling of the word and fixes the most-popular claim—and then you had Git attempt to combine your change with theirs, using git rebase.

You can, of course, choose to switch the spelling back to color, but let's say you choose to keep the British spelling. In this case, the correct resolution of this merge conflict is to drop your change to the file.

If that was the only change in your entire commit, the correct resolution is now to drop your commit entirely. The git rebase command will give you this option! You must simply inform Git that this is the case, with:

git rebase --skip

Be sure this is the correct option before using it.

Maybe my process is wrong...

Whether to rebase or merge is both a personal and a team decision. One size does not fit all here. Only you and your co-workers / team can decide this.

If you choose to combine your commit with their commit using git merge, you do not get an option to discard your commit entirely. Merge adds new commits, rather than copying existing commits; the existing commits all remain, so there is no way to drop a commit. You would, however, not be facing this issue if you were doing a real merge, instead of a rebase: git merge --continue or git commit—either command does the same thing at this point—would make the new merge commit, which would have, as its snapshot, whatever resolution you chose for this merge conflict.