Let’s use gitserver as the hostname of the server on which you’ve set up your git user and repository. If you’re running it internally, and you set up DNS for gitserver to point to that server, then you can use the commands pretty much as is (assuming that myproject is an existing project with files in it). What is GitStack? GitStack is a software that lets you setup your own private Git server for Windows.This means that you create a leading edge versioning system without any prior Git knowledge. GitStack also makes it super easy to secure and keep your server up to date. GitStack is built on the top of the genuine Git for Windows and is compatible with any other Git clients. Now Git network commands will still work just fine but the users won’t be able to get a shell. As the output states, you can also set up a directory in the git user’s home directory that customizes the git-shell command a bit. For instance, you can restrict the Git commands that the server will accept or you can customize the message that.
This is a clear and simple step-by-step tutorial showing how to set up a git repository locally and on a remote server. You will need this for sharing your work with other people and/or machines.
Creating a new git repository on your local machine is a very simple operation which gives you a full working directory. Basically a git working directory is a local repository which tracks revisions of your files and a history of your commits.
In case you wanted to share your files with other people or access them from other machines, all you need to do is to create a bare repository on a server and push your changes there. A bare git repository is a special repository without a working directory. When you create a bare git repository it only contains git objects and it will only contain git objects even after you start pushing content to it. Git objects are files used by git to keep track of all your data and its multiple revisions.
For this tutorial I am assuming you will be setting things up on a Linux server, but the process is pretty much the same on other operating systems.
The first thing you need to do to set up a git repository locally is creating a new directory and move to it
Now you’re inside your project directory and you can create a git repository with the following command:
Listing the content of the directory will show you something like this:
As you can see git created a hidden directory which it uses to keep all the files it needs to track your work.
Now your local git repository is ready to use and you can work in it and commit your changes following a workflow similar to this:
Once you have finished on your local machine you can move to the server.
Now that you are on the server you have to reproduce the same steps from the previous section for creating a git repository. There will be few minor differences, but core concepts are pretty much the same.
The first thing you want to do is to create a directory to store the bare git repository. I usually keep all my repositories in /var/repo/git/, but you can use other paths like /home/git/ or anything you prefer.
This time the directory ends with .git because we are creating the bare repository and not a working directory.
Now let’s initialise a bare git repository from the newly created directory with the following command:
Listing the files in the directory will give different results this time:
It might be interesting to know that these are the same files you will find in the .git directory created by git in your local working directory.
In my case both the new directory and all the files in it are owned by the user root. That means that git can’t write them and we need to fix that before continuing:
chown -R git .
chgrp -R git .
Now the content of the bare repository should look like this:
This means that now git has full access to all the files contained in the bare repository directory.
Once the working directory and the bare repository are set up it’s time to connect them to save your work on the server and eventually share it with others. This is done by the following command:
This command doesn’t show any output message on success, but you can verify everything is fine visualising the tracked repositories:
Now your local working directory is connected to your remote bare repository and you can push changes to it.
Now that the local working directory and the bare repository on the remote server are connected you can push changes to the latter.
You might be tempted to try a simple push, but that will give you an error:
That’s because you need to specify an upstream branch (the one used by default when no branch is specified) and associate it with a remote one. You can do that with option –set-upstream or its shorter version -u as showed next:
This will also push all the changes in the local branch master to the remote server origin.
From now on git will keep pushing changes from master to origin every time you use the git push command.
You might be interested in reading more about the git commands mentioned in this tutorial:
I hope you enjoyed this tutorial explaining how to set up a git repository locally and on a remote server. If you have any question feel free to leave a comment.
If you found it useful, please share it on social media using the social buttons below.
Don’t forget to subscribe to the blog newsletter to get notified of future posts (once a week).
You can also get updates following me on Google+, LinkedIn and Twitter.
While Mercurial still hold a special place in my heart it can’t be denied that Git has well and truly won the war. Because of this I’ve been using it more extensively in the projects that I work on.
Recently I started on an engagement at work that was using TFS as its SCM, but wanting to avoid some of the pain of TFS 2010 I decided to use git-tf. Things all went smoothly, git was communicating nicely to TFS and children danced around the world.
When the partner who owned the TFS instance rolled off the project the SCM went with them which left me in a pickle, I still had a few weeks left and was looking at the prospect of being SCM-less. For various security reasons I can’t utilise any of the normal hosted SCM’s that I’d go with, so I was left with a problem, I have a complete git history of the project but the only place it lived was on my desktop.
Having used Mercurial for around 3 years now I’m quite familiar with the hg serve command, this is ideal as you run that and you immediately have a basic Mercurial server running that you can push and pull to. This is exactly what I want for git, I’d have a simple server that I can work against and so can the other developer who was coming in few a few days. Unfortunately there is no such command, you do instead have the git daemon, and with a simple command like this:
You’ve got yourself a git server. Yeah go on, remember that off the top of your head (yes you just type it once in as an alias I know I know :P)!
So I run my command, have my server ready for connections and then shit gets ugly.
As it turns out msysgit, the de-facto Windows git tools, has some real problems with
git daemon. I was continuously seeing this while trying to clone:
Eventually a clone would go through (it’s only a 10mb repo!) but then you’d get a whole different set of problems.
Again, as it turns out msysgit doesn’t support pushing to
git:// repositories on Windows. Well that just sucks then doesn’t it, it left us with sneakerneting our
.git folder so I could maintain the master repository.
And that got old fast!
So now that msysgit was out the next idea was to use cygwin. I’ve been avoiding installing cygwin on any machines for quite some time now as it really frustrates the hell out of me but I got sent this stack overflow post which made it seem quite easy to get it up and running.
Well I followed the instructions and started up my sever and it all seemed good, I could pull from it without any problems. Yay!
But of course it was time for another problem, I kept having
git push hang at 100% of writing objects.
Again this seems to be a fairly common problem with git on Windows pushing to cygwin git daemons and to which there’s no decent solution.
Basically all my research has suggested to me that the idea of trying to host a git server on Windows is just a bad idea. Sure there were other avenues that I hadn’t tried, such as using a network share to store my git repository and push/ pulling over that, but I didn’t want to futz around with network security here for this task (people also suggested using Dropbox but that is nullified by the fact that the source can’t be hosted outside of the local network), I just wanted a damn git server and my only remaining option that I could see was Linux.
Since my machine is running Windows 8 I’ve got Hyper-V built in so that’s one problem down, I didn’t have to install VirtualBox (its installer wants me to trust Oracle, I just can’t do that :P) or VMWare Player or anything like that, just enable a Windows feature. The next question, what distro to use…
Wow, there’s a can of worms you can open, ask people what Linux distro to use… I’ll admit that it’s been quite a few years since I last used Linux so I’m not really up with what the kids are using these days but all I want are:
So ArchLinux and PuppyLinux were two of the top recommended distros, but they’d require a bit of setup to get running. Then a colleague of mine recommended GitLab, a variation of Turnkey that is basically just a pre-built git server. Sweet that sounds exactly like what I want.
I downloaded GitLab, booted Hyper-V, attached the ISO and kicked off the installer. After being prompted for some credentials to log in and having to use the Legacy Network Adapter in Hyper-V (apparently Turnkey supports the standard one but 5 minutes of configuring modules didn’t work for me so I went ‘meh, legacy it is’ :P) my git server was up and running!
For the record my VM specs are a 5GB hard drive and it has 512mb RAM dedicated to it. I was tempted to drop it down to 256mb as it really just idles mostly but I’ve got RAM to spare.
Next step was to log into the web portal, setup a git project on the server and add my public key and it just worked. Seriously, I was shocked that it was that simple!
I even managed to get the other developer (who prefers GUI tools over command line, weirdo!) setup to use GitHub for Windows against my GitLab server.
Want to run a git server on Windows? Don’t bother, install GitLab, it takes about 10 minutes to be up and running with that in a VM.
The more I’ve been using GitLab the more I’m liking it, it’s got a nifty little web UI, we can see the repository information, all that fun stuff that distracts you from actually doing work.