CODEWITHSUNDEEP
gitgithub
David Folkner
David Folkner

Reputation: 1199

Git Auto Rebase Issues

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?

Upvotes: 0

Views: 960

Answers (3)

Juha K
Juha K

Reputation: 324

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.

Upvotes: 1

Code-Apprentice
Code-Apprentice

Reputation: 83527

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.

Upvotes: 0

VonC
VonC

Reputation: 1323943

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.

Upvotes: 2

Related Questions