feasibility of git without a remote repo

Question

So it seems to me like the most basic of git operations could be done effectively without a remote. ie. You could add and you could commit without a problem.

It seems like the biggest problem with a git repo without a remote would be stuff like git reset . Like if you want to revert your code to a particular commit twenty commits ago - just to test to see if something worked back then or something - it doesn't seem like you could do it. You do git reset --hard ... and then you've lost your twenty newest commits and there's no way to get them back.

What else wouldn't work?

Answer 1

There are multiple ways to avoid the problem you're concerned about.

You can be pro-active, as @mamapitufo suggests, and create a branch before you do anything like git reset --hard . This is fine, as long as you remember to do it regularly.

If you're less than clairvoyant, use git reflog after you realize you've lost some commits you want. git retains unreachable commits, that is, those that can't be found from any branch tip, in the repository for 30 days. git reflog branch-name shows all the recent changes to the head of the named branch, and from that you can use git reset --hard again to get back to where your were.

You can use git checkout sha1 to move around in the history without changing your branch tips. When you're done exploring, use git checkout branchname to get back in sync with a branch head.

Finally, if all else fails, you can use git fsck to look for dangling commits. If git fsck can't find the commit you want, only then has it probably been purged from the repository.

By the way, a remote repository can be another one on the same machine, so you can still use git's remote repo features even without a network.

Answer 2

You can create a branch that points to the specific commit you want and switch to it:

git checkout -b test-branch <commit-id>

When you are done with it you can get rid of the branch:

git checkout master
git branch -d test-branch

Answer 3

I never reset for testing, just checkout to that commit, yea you will be on a detached head mode but who cares, you are only testing, if you decide you want to reset then then do it. I always do this

git checkout HEAD~

which means go back 1 commit from current head, when I'm done I can simply checkout back to the branch name because it's still pointing to the original commit

git checkout master # or any other branch

and to create a new branch from the current commit you can do

git branch some-new-name

if you need to create a new branch and checkout to it you can do checkout -b like @mamapitufo suggested, but no need for commit id, by default it takes current HEAD as the new branch.

As a side note, even if you don't want to create a remote, it's useful to have another backup somewhere else, which is "the remote", the remote could be another folder in the same hard disk, or a network folder, or a network pc, just think of not like not keeping all your eggs in one basket.

PS: Actually git reset would work, because git by default doesn't remove any thing right away, if you really really want to reset, if you still have the old commit hash you can reset back by doing git reset <hash> and there you are back.

But keep in mind that doesn't include uncommitted files nor untracked files.