本地 git 远程仓库丢失主分支

Question

After looking through the SO answers, I cannot find anything that comes close to what I think my problem is right now.

Being fairly new to git, I started a new project by following some of the newby recommendations.

My setup: a local NAS has the original master git repo, started by adding code from a directory with code not under git control. Using TortoiseGit (TG) I added the base code and kept modifying, compiling and committing to the local repo and then pushing to the NAS repo.

Initially, all went the way all of the tutorials show, but at one point I wanted to create a branch to test code meant to resolve a specific issue, which kept going for some time and became the de facto master branch. Somewhere along the line I wanted to merge this back into the master, but I made some bad choices, it seems, and now neither my supposed master nor my local repo any longer has any master branch and only one branch named Branch_new.

While in theory I assume I could just carry on on this mislabeled branch, I would prefer to get back to a more conventional setup.

At this stage it is not very important that I keep all of the history and I could simply start over by pretending that the current code is my initial base, but as part of learning a bit more about the git way of doing things, I would prefer to learn how to extricate myself from the mess things are in.

TIA

Answer 1

First of all, not everything is lost. By default, git cleans up commits which are not referenced by any branch only after two weeks (see git help gc ). If two weeks have not passed, then you might recover your work.
Now getting to find these commits might get a bit tricky. There are different methods to achieve this, I like the reflog best. You can access it by either git reflog command, or looking at the raw file under .git/logs/HEAD , which will show you all the places (commits) that you've been at, and the command that made git switch to that commit or branch.
Once you find your commit, recreating a branch from it (to save it from garbage collection) is as simple as git branch <branch_name> <commit> . You can verify the history beforehand by git log <commit> , as all commits point to their ancestor, so you'll have the complete history up to that point.

As for what caused the mess you encountered, I cannot be sure without the reflog and the history of all your commands, starting from initializing the repository. I did find, however, that most problems with new remotes happen due to the remote not being a bare repository (which sounds like the case from what you describe). Remotes that you push to need to be bare, ie not have a working directory, but only the git metadata (whatever a regular clone will usually have under .git/ ). That's because pushing to a repo which has a branch checked out does make a mess.
When initializing a repo that you want to act as a remote (so you can push to it), you should make it bare. Read a bit more on git init --bare or git clone --bare , these should get you started setting up a remote correctly.
Note that even if a repo is not bare, you can still clone from it. This causes most of the confusion around pushing to new repos.