On conflict, GitHub for Windows puts me in "rebasing" state, how to go from there?

Question

I recently started using GitHub for Windows.

I just got a conflict. On command line I would know how to handle this, but GitHub for Windows choosed to put me in a state I am not familiar with:

C:\Users\w\Documents\GitHub\CmisSync [(6026d18...)|REBASE +0 ~1 -0 !1 | +0 ~0 -0 !1]> git status
# Not currently on any branch.
# You are currently rebasing.
#   (fix conflicts and then run "git rebase --continue")
#   (use "git rebase --skip" to skip this patch)
#   (use "git rebase --abort" to check out the original branch)
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
...

I fixed the conflict, committed the files, but when I run git push I am told:

fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD) state now, use

    git push origin HEAD:<name-of-remote-branch>

What is the recommended way to get my merging commits to the remote master?
I doubt git push origin HEAD:master will achieve this.

Solution 1

As we where saying with Simon Boudrias, if you don't really know what you've done during a rebase, the best thing to start off is with a git rebase --abort. As the verb says, it aborts the current rebase, and leaves you with your repository and working copy in the same state it was before the rebase started.

After that, you should do whatever you've done that started the rebase process (I don't think you said what it was, but don't think it's really important, either). Surely the rebase will start again, and here is where your original question begins to be answered.

As the status output says, you seem to have conflicts. You should resolve them (I usually use git status --short plus git mergetool to resolve them with meld), then git add the files. When status is OK (say, every file that would have to be commited is added, with no conflicts), you should git rebase --continue instead of git commit.

The idea is that git rebase applies a group of commits on top of a given commit. I don't really know what commits are being applied on top of what, but it's important to have that in mind. Keep in mind that there can show multiple conflicts, because commits apply one by one. Use git log to see what was the last commit applied, and I think there has to be a file in your .git/ directory with the commit message of the commit that's currently being applied.

It's a commmon newbie error (we've all been there :)) to try to include changes in the files during the conflict resolution without knowing (or forgetting) they were going to be applied by a latter commit.

So, hopefully, after resolving some conflicts, adding the files and git rebase --continueing them, you should arrive to a happy functional repository, and you'll be able to git push from there on.

Lastly, but not least important: after all the rebase stuff, use git log to check you're not modifying any public commit. Say, that your new branch contains the remote's HEAD commit. Rebasing is powerful and very dangerous. You don't want to rebase a public commit - it's maybe the only git pain you don't want to face :)

Solution 2

You first need to end the rebase mode by calling git rebase --continue once you resolved your conflicts. This should then put you back on the branch you were pulling (in your case master). You'll notice this happens when the command line (posh-git plugin) will indicates master instead of REBASE

Then you could push using git push origin master. The extra parameters may be autofilled by Git, but that'll depends on your settings.

Comments

[mgarciaisaia]

At this point, he probably have made a mess while trying to commit and push during a rebase. Running git rebase --abort and re-doing the actions that left you with the rebase seems to be a good idea.

[Simon Boudrias]

Good point, it's always good time to abort and start over when you've made a mess. Thanks for adding this.

[Nicolas Raoul]

Simon, I tried doing this, but I got No changes - did you forget to use 'git add'?, so I did exactly what @desert69 did, and that worked. @desert69, could you please post your idea as an answer? Thank you!

[Simon Boudrias]

If you abort the rebase, you just came back to the point you were before the pull. You still need to pass through the rebase step. You need to git add the changes you made to resolve conflicts before calling rebase --continue (don't commit while in rebase mode).

[martin jakubik]

what do you mean by "check you're not modifying any public commit"?