Good version control is one of the cornerstones of proper development practices. There are plenty of services for managing git repositories, but they aren’t required. Git at it’s core allows you to create your own in any directory.

Why would you want to host your own repository? The main reason is that it’s easy. If you want to have your code deployed on a server, but you don’t want to have to introduce dependencies on some remote service, you can’t push directly to a live deployed git instance. Git instances exist at a certain branch state. If you push code to this live branch, it would have to live update the code that is currently deployed and potentially create branch conflicts.

How does git resolve this issue? It won’t let you do this. If you try to set an active repo as an origin for your remote repo, it will choke and throw an error. Instead, you have to enable baremode.

To start you will have to create a set of directories on your host server. For example to make a new repo called reponame:

mkdir -p ~/repos/reponame
cd ~/repos/reponame
git init
vi .git/config

You will want to edit the config to enable baremode:

[core]
	repositoryformatversion = 0
	filemode = true
	bare = true
	logallrefupdates = true

Now, you can from your local machine set your remote repository:

git remote add origin username@hostname.com:~/repos/reponame/.git

From your server, if you want to deploy the code locally you can reference your local repo:

git remote add origin ~/repos/reponame/.git

Now from your local machine, to deploy you run git push origin master; and from the server you run git pull. Obviously you will need passwords or ssh keys set up properly for authentication from your local environment. Git defaults to connecting via ssh by default, so your core linux libraries will handle all of the connection details for you once you have your system wired up.

It can get a little more complex if you want to have live changes on your server be different from what you are publishing from your local branch. In that case, from your server you will want to run in a different branch for production.

So for example, git clone -b prod from your server working directory. You can merge your changes from your master branch on the server using git pull origin master, which will take your deltas and merge them.

Obviously you will have merge conflicts when checking out if you make changes any files that have local changes in your production directory. From the server commit your local changes, and git push origin prod. You can then resolve your merge conflicts by merging your prod changes either on your local machine or in a separate server working directory by pulling from the prod branch using git pull origin prod.

Unless you have good reason not to, it’s often a good best practice to merge your prod changes back in to master before attempting to publish.

There are some really nice tools you can set up if you want to be able to browse your own repositories via the web, like GitList. It’s pretty straightforward to create a subdomain on your host and add services like this from most web providers, and GitList is pretty easy to configure.

That’s all it takes. Now you’re effectively running your own GitHub. Remember to never put your .git folder in a public served folder.