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

Answer 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 :)