The trouble with searching the Web for instructions relating to git and using your own git server is that mostly you will find articles for working with someone else’s repository server (like GitHub or so many others). You can find quite good instructions for interacting with a remote server from your local development machine, but there are so many such instructions out there that locating useful information about using your own server to host git gets buried pretty deep.
Let’s go over some of the most basic pieces, and if you know how to use git with someone else’s repository server then you will be in good enough shape to sort out your specific situation.
First we need to differentiate between the served repository and any local copy of the files you might like to keep. You don’t necessarily need to keep a local copy of the files on the server since the repo contains enough information to rebuild the files at any point, but I’m going to show you how because I wanted mine to include server-held local copies of the files.
On your server you’ll want to create a bucket for holding any and all of your git repositories (I broke mine into projects plus an archive folder). So your paths may look like this:
## /media/storage/git /media/storage/git/project1 /media/storage/git/project2 /media/storage/git/zzArchive /media/storage/git/.repos /media/storage/git/.repos/project1 /media/storage/git/.repos/project2 /media/storage/git/.repos/zzArchive ##
In the above example, the folder I’ve called git is just the bucket which holds the local copies of the repository files, and should not be used itself as a repository. (If you are only planning a single repository I would still recommend using this structure as a way of being ready for the future.) The folder I’ve called .repos is the bucket which contains the git repositories; these sub-folders do not contain any of the actual files but rather just diffs which allow git to rebuild the files at various stages. You will see that I have a one-to-one correspondence between the .repos sub-foldders and the local copy folders above.
Move into each directory under .repos in turn and perform these actions. Here we will just pick project1 and go through the steps.
## cd /media/storage/git/.repos/project1 git init --bare ##
This will create an empty repository which you can clone, add files, and make commits. This is how to make your first copy (of the empty repo) and add files.
## cd /media/storage/git git clone yourusername@localhost:/media/storage/.repos/project1 # now move into the newly cloned directory... cd project1 # here you will want to add any existing files to this folder or create a new file then... git add . git commit -m "initial commit of new repo" ##
Now you have a good master to begin.
From your laptop or workstation or any other computer you can perform these cloning steps above but substitute the name of your server machine for localhost in the clone command above. (This uses ssh for reading and writing to git. You can find instructions out there for http if you’d rather use that. I prefer ssh.)
You won’t need to use git add until there is at least one file you want git to know about. Commits just let git understand that anything git knows you have changed is to be regarded as canon.
Add some files and make some changes. Then move into the project directory to add, commit, and push.
## # move into some folder, probably called git, where you want to store your git repos git clone yourusername@yourserver:/media/storage/.repos/project1 # now move into the newly cloned directory... cd project1 git add . git commit -m "useful commit message so you remember what the fuck you did" git push ##
If you set up a local copy on your server like I did above, you will want to regularly git pull into that copy so the files stored there are as up to date as possible (when you run your backups for example).
As near as I can tell this is the best way to manage that for oneself. If there are better practices than those I’m using here, I’d like to see the detailed explanations for making them work and why they are a best practice. Let me know.
Otherwise, have a great time with your newly minted git server.
