Git for the Antisocial: Setting Up a Local-Only Git Repository

Scenario: You want to use git but you don’t want to expose your code on a site like GitHub and you don’t want to deal with setting up your own remote repository from scratch. You want a simple, private, LOCAL repository. Is this possible with git? Is it possible to use git locally? Is it possible to use git without GitHub?

For all that git is often described as a “distributed” version control tool and sometimes confused with GitHub itself[1], you can and should sometimes be using git locally (without GitHub) if you’re using git (or GitHub) at all. Git may not be appropriate for every project, but more importantly, GitHub isn’t an appropriate venue for every project that uses git. Since setting up a local-only git repository takes all of ten seconds…

git init myRepoFolder --bare
git clone myRepoFolder myWorkingFolder

…it seems pointless to shell out money for a private repository on GitHub when a local git repository will do, and it’s putting the cart before the horse to “learn” GitHub before you’ve learned the basics of git. If you don’t need remote multi-person access, don’t use GitHub. Just use plain old git. Simple.[2]

In addition to the standard init-and-clone method shown above, you can also turn an existing folder into a git working folder by explicitly initializing the folder and setting the remote:

git init myRepoFolder --bare
git init myWorkingFolder
cd myWorkingFolder
git remote add origin myRepoFolder

For more information, check out the git init and git clone commands and keep in mind that all you’re really doing in a “local-only” git repository is setting the upstream repository to a local folder on your hard drive instead of say, a repository on GitHub. It’s a normal repo in all respects, and you can use your favorite git client (including GitHub’s own desktop client) to interact with it.

If down the road you decide you want to expose your project to the community, great. That’s what GitHub and other sites are there for. Otherwise keep your git repos right where they belong: on your local hard drive or your organization’s internal server. That’s the default primordial use case of git. Just don’t forget to celebrate International Backup Awareness Day as not even git revert can rewind time and prevent the catastrophic hard drive failure before it doesn’t occur. That’s on you.

[1] It’s a testament to the popularity of GitHub that new developers sometimes mistake it for its namesake, considering that GitHub and git are not only two different things, but two different classes of things. Confusing git with GitHub isn’t confusing apples with oranges, it’s confusing apples with helicopters.

[2] Even if you do need remote access, setting up your own remote repository on your organization’s hardware is often a better and more secure choice than paying for a private repository maintained by a 3rd party, however trustworthy.

Comments

  • uncloaked says:

    Only newbie GitHub users would make the mistake of confusing git with GitHub. That said, this question on stackoverflow makes me think there are a lot of git newbies who’ve been lured in by the GitHub community without bothering to learn git.

  • Daniel says:

    What is the purpose of the bare repository? I don’t see why you would need two copies of the same repository locally if you’re not sharing it and need to create a cleaner “canonical” repository without crufty short-lived or experimental branches. It certainly doesn’t seem simple when you could easily just have a single repository, singe git is completely self-contained. Unless, of course, you intend this for people who want a way to “practice” working with a remote repository.

  • Leave a Reply