Git Auto Rebase Issues

Question

We are very uneducated git users that generally sync many files through GitHub using a single master branch and merging that since we have very little overlap in execution.

On rare occasion, we'll get a random rebase branch that will come up out of nowhere. This happened recently.

We attempted to merge it with our main master branch by performing a git rebase --continue with no conflicts. Then performing a git checkout master, and we wanted to follow that with a git merge RANDOM REBASE, but it all seems gone and we've lost important committed data on that strange random rebase branch.

How can we recover it?

What is a "random rebase" branch, and why would you be wanting to _merge_ it with `master`? Typically, you would rebase a feature on `master` in order to fast forward the latter branch by just playing commits on top of it. — Tim Biegeleisen, Dec 16 '16 at 03:43
When using github for windows it shows up as another branch with a name like (fj%74 (REBASE) — David Folkner, Dec 16 '16 at 03:44
I think it will take too much back and forth for this to be an answerable StackOverflow question. Please close this question and try somewhere like the #git IRC channel, to dig into the details needed to unravel the problem. — Andy Ray, Dec 16 '16 at 03:46
I think you're confused about how rebasing works. Typing `git rebase --continue` is how you _complete_ a rebase operation, but this implies that you did `git rebase` at some point to initiate a rebase, and it isn't clear why you would be doing this. — Tim Biegeleisen, Dec 16 '16 at 03:51
As others have already commented, it appears that you are confused about the differences between a merge and a rebase. If you want to try to salvage this question, you need to provide more information. In particular, you should give the names of the branches you are working with and the commands you did before `git rebase --continue`. You had to already start a rebase in order to continue it. That's the meaning of the word "continue". — Code-Apprentice, Dec 16 '16 at 05:57
Are you by chance using the desktop app GitHub for Windows (edit: nvm, you are)? The "Sync" button in the app can do weird stuff automatically if you have conflicts (ie. two people have edited the same file simultaneously). If you don't know how to use basic git commands (referring to "uneducated", and if you actually are using the app rather than command line), it can be hard to sort out the mess. — Juha K, Dec 16 '16 at 06:34
I see now that you are using Github for Windows. Most of the answers won't help you then, since you probably are not used at all to handle the actual git commands behind the GUI. — Juha K, Dec 16 '16 at 06:37

score 2 · Answer 1 · edited May 23 '17 at 12:24

When using github for windows it shows up as another branch with a name like (fj%74 (REBASE)

As shown in this question:

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.

it is not a branch, but a git bash prompt illustrating that:

a rebase is in progress
you need to continue and complete the rebase (or cancel it)

As mentioned in the answer:

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

Or look at "Undoing a git rebase": between git reflog and git reset --hard ORIG_HEAD, you can go back to a known state before that rebase.

score 1 · Accepted Answer · edited May 23 '17 at 12:24

As you're using the Github for Windows app, I'm trying to write this answer in terms that should be easy to understand for people unaccustomed to git commands.

In Github for Windows, the Sync button actually executes many git commands as described eg. in here. If the Sync button is all you've been using, the following scenario can lead into new branches and weird merge commits:

person A has edited file xyz
person A commits & syncs xyz into master
person B edits file xyz without first syncing (ie. B is editing an old version of xyz)
person B commits & tries to sync xyz
Github for Windows attempts to automatically handle the situation
this can lead to a new branch being created from the common startpoint of A's and B's changes, with B's commit on this new branch and A's commit on master
this new branch will then be automatically rebased or merged (depending on conflicts & such) on master

Unfortunately, occasionally Github for Windows botches up the rebase. Then you get an error message in the GUI and need to figure out the situation in Git shell. If that is the case, usually I've found the only workaround option is aborting the rebase using git rebase --abort, undoing B's commit from the GUI (if possible), and restoring B's workspace to the master branch that includes A's commit. Then B can re-apply her changes on the file that includes A's changes.

The Simple Person's Workflow for Github for Windows should usually be "Sync, change, commit, Sync", so that you get all the previous changes before you edit anything. Using the actual git commands in the shell is still a preferred option.

score 0 · Answer 3 · answered Dec 16 '16 at 05:52

If you truly want to merge branches, you should do git merge <branch name>. The command git rebase --continue does not peform a merge. Instead it continues an already started rebase operation which is very different from a merge. Also, if you are doing this command, it means that you must have done a git rebase <branch name> previously. Branches don't just appear from no where. They are created when you perform commands, usually git branch or git checkout -b. If you truly need to use git rebase, you should read more about how it works. Git Pro is a free online book with a good chapter on Branches and Rebasing.

Git Auto Rebase Issues

3 Answers3