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.

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 BiegeleisenDec 16 '16 at 3:43

When using github for windows it shows up as another branch with a name like (fj%74 (REBASE)
– David FolknerDec 16 '16 at 3: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 RayDec 16 '16 at 3:46

1

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 BiegeleisenDec 16 '16 at 3:51

3 Answers
3

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.

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.