Home » Git » Git Server Like GitHub? [closed]

Git Server Like GitHub? [closed]

Posted by: admin November 15, 2021 Leave a comment


I am a long time Subversion user that is going to try Git. I have read some about it and understand the distributed nature – I can see a lot of the benefits.

However, I do like the idea of a central server that can take on the role of backups, system of record, etc, while still using Git for my local branching and sharing. I am not doing an open source project, so I can’t use Github (without paying), so my question really is: what is a best practice way to run a local git server?

I realize this may be against the standard Git usage pattern, but it will be useful for my project. Any concerns that I may have overlooked are always welcome, however.



You can just set up an ssh server and run a central repository there. All developers then simply agree (as a matter of policy) to push to the server when they are done making commits. This is the usage pattern at my workplace. Very CVS and SVN-like.

  1. Find somewhere to put the repository (/var/gitroot for example).
  2. Create a new repo (mkdir project.git && cd project.git && git init --bare --shared=group).
  3. Then on your client, clone the remote repo (git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
  4. add some files (git add README)
  5. commit (git commit -m "Initial import"),
  6. push (git push origin master)

This should set things up for you.


Gitorious is an open source web interface to git that you can run on your own server, much like github:



http://gitlab.org/ is another alternative now as well.

Update 2:

Gitorious has now joined with GitLab


Try GitLab

The best git GUI tool i have ever used. It is very similar to GitHub.

It is open source (MIT License) and is the most installed git management software with over 25.000 installation. It has monthly releases and an active community with over 375 contributors. You can have unlimited private, internal and public repositories on your own server. It is a Ruby on Rails app that runs on most Unix platforms.


If you don’t mind getting down and dirty with the command line, gitolite is an absolute treat when working in a corporate environment where you need to set differenct access rights on different repositories. It is sort of a newer version of gitosis mentioned by @Chris.

Here is the summary from the author’s web site:

Gitolite lets you use a single user on a server to host many git repositories and provide access to many developers, without having to give them real userids on or shell access to the server. The essential magic in doing this is ssh’s pubkey access and the authorized_keys file, and the inspiration was an older program called gitosis.

Gitolite can restrict who can read from (clone/fetch) or write to (push) a repository. It can also restrict who can push to what branch or tag, which is very important in a corporate environment. Gitolite can be installed without requiring root permissions, and with no additional software than git itself and perl.

It has quite a comprehensive feature set, but one thing I like very much, is that all of the day to day configuration editing is done through a special git repository. That is, adding a user is just

  • Add user to configuration file
  • Add the user’s ssh key
  • Commit the change
  • Push it to gitolite
  • Voila, the configuration is live!

And when needing to look at the code through browser, gitolite has support for "syncing" configuration with gitweb. Or if you like cgit, which is a very good web frontend for git written in C, better, then you should look at this how-to.


You might consider Gitblit, an open-source, integrated, pure Java Git server, viewer, and repository manager for small workgroups.


Bare Bones Browser

git instaweb --httpd=webrick

from the git scm book

combine it with something like the approach described here for distributed development (credit to datagrok for the well described concept)

Launch a one-off git server from any local repository.

I tweeted this already but I thought it could use some expansion:

Enable decentralized git workflow: git config alias.serve "daemon –verbose –export-all –base-path=.git –reuseaddr –strict-paths .git/"

Say you use a git workflow that involves working with a core "official" repository that you pull and push your changes from and into. I’m sure many companies do this, as do many users of git hosting services like Github.

Say that server, or Github, goes down for a bit.

No worries, after all, one of the reasons you use git is so you have a copy of the entire project history in your local clone.

You can keep right on coding and committing, while you wait for the operations team to bring the server back to life. Note to self: buy doughnuts for operations team.

But what if, during this downtime, you want to collaborate with another person, who may not be a git expert, on the same repository?

Or, instead of downtime, what if you and your collaborator are in the field, and for some reason you can’t get your VPN to let you connect to your official repo?

Or, what if you and your collaborator are spiking out a bunch of experimental changes, and even though you have access, you don’t want to push your unfinished mess into the official central repository? (Not even as feature branches.) Maybe you’re in the middle of cleaning up a disastrous rebase or merge and the branches are all over the place.

Well, git, as you are probably aware, is a "distributed" version control system.

Even though you might use a central "official" git repository in your workflow, you still have the ability to use git in a peer-to-peer manner, where you and your collaborator simply build and share commits with each other, and the central server never even has to know.

So, how do you get your branches and commits over to them, or vice versa?

  • You could use git’s facilities for e-mailing patches. But that’s a bit inelegant and requires some knowledge on their end of how to apply e-mailed patches.
  • You could create an account on your own machine for your collaborator to ssh into. But maybe you don’t have local root access, or maybe you don’t trust them with SSH access to your box.
  • You could clone your repo onto a thumbdrive and pass it back and forth. But that’s rather tedious, especially if you happen to be on the same local network, and requires a thumb drive.

You can probably think of other methods, too. But there’s a super easy way: if you can see each other on the network, you can launch a one-off git server that they can use as their remote to clone, fetch, and pull your changes, and kill it when you’re done with it.

The tool that enables this is git daemon, which has a lot of options and functionality, but for the purpose of enabling this easy one-off "just serve up the repo I’m in," the way to use it is to create an alias. I like to call it git serve. Run:

git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

Using an alias is actually crucial, because git aliases are executed in the base directory of your working tree. So the path ‘.git’ will always point to the right place, no matter where you are within the directory tree of your repository.

Use your new git serve like so:

  1. Run git serve. "Ready to rumble," it will report. Git is bad-ass.
  2. Find out your IP address. Say it’s
  3. Say "hey Jane, I’m not ready/able to push these commits up to origin, but you can fetch my commits into your clone by running git fetch git://"
  4. Press ctrl+c when you don’t want to serve that repo any longer.

You could also tell Jane to git clone git:// local-repo-name if she does not yet have a clone of the repository. Or, use git pull git:// branchname to do a fetch and merge at once, useful if you are working together on a feature branch.

Note however that you shouldn’t do this on hostile networks if you keep secrets in your repository, because there’s no authentication. It doesn’t advertise its existence, but anybody with a a port scanner can find it, connect to it, and clone your repo.

But it’s not super dangerous because it is read-only by default. Read the git daemon man page carefully if you think that you want to enable write access. In the case where you want to obtain your collaborator’s commits, it’s much safer to leave it read-only, and ask your collaborator to also run this command, so you can pull from them.

Tangentially related: on the subject of one-off servers, if you want to temporarily share a bunch of static files over HTTP: python -m SimpleHTTPServer


If you need good, easy GIT server than you must try GitBlit.
Also i use gitolite but it only server, with GitBlit you get all in one, server, admin, repos. manager … URL: http://gitblit.com/


https://rhodecode.com is an open source web app for Git & Mercurial which can be very easily installed under any operating system (an installer is included).

RhodeCode (the new version is called RhodeCode Enterprise) adds missing Git features like code review and it is generally speaking very fast and reliable.


You can also install Indefero, it is a GPL clone of GoogleCode, as it supports both Subversion and Git, you can have a smooth transition. I am the author of Indefero.


You can even install GitHub on your local server (but not for free):



It may not be the most common git server setup, but having played with different layouts, tools, mirroring and permission schemes, I’d say one pretty solid alternative for enterprise repositories is Gerrit, which may seem surprising as it is more known as a code review tool. We started using it as code review and it slowly became our main repository, deprecating g3/gitolite

  • It is straightforward to deploy (you basically drop the .war in a tomcat)
  • has a web ui to manage repositories, groups and permissions (or a ssh cli)
  • has a built-in java ssh and git implementation, so you have nothing else to set up
  • ldap support for users and groups (usually a must for companies)
  • a very flexible permission system (with project groups, permission inheritance, restricting read/write/branching/unreviewed writes/etc)
  • code review capabilities (if you’re into that thing)
  • repo mirroring (to push some repositories to github or other public repo)

In addition, it’s used by large projects (e.g. android, chrome) so it does scales and is now fairly solid. Just give your users the PUSH permission if you want to allow bypassing the code review part.


For a remote hosting As others have said bitbucket.org offers free private repositories, I’ve been using it without problems.

For local or LAN network
I will add this one scm-manager.org (A single executable file, is really simple to install, it’s made on Java so it can run on Linux or Windows). Just in case you install it, these are default passwords.

Username: scmadmin
Password: scmadmin


In the meantime, the Mercurial hosting site Bitbucket has started to offer Git repositories as well.

So if you don’t need a local server, just some central place where you can host private Git repositories for free, IMO Bitbucket is the best choice.

For free, you get unlimited private and public Git and Mercurial repositories.
The only limitation is that in the free plan, no more than five users can access your private repositories (for more, you have to pay).
See https://bitbucket.org/plans for more info!


If you want pull requests, there are the open source projects of RhodeCode and GitLab and the paid Stash


If you just want your repository in a central place, this is quite easy with distributed version control like Git:
You can just put your central repository in some shared folder on a central machine and everybody can clone it from there.

If you want a “real” website on your local server, I know of the Git hosting website http://repo.or.cz.
It seems to have less features than GitHub, but unlike GitHub, you can get the source code and host it on your own local server.

Disclaimer: I only read about repo.or.cz, I never tried it myself!


for simple setups, you can provide ssh access to a central server, and set up each user’s working directory to push/pull from this ‘origin’. That would be the most simple and common setup for small teams.

You might also look into gitosis which gives you an http server and the ability to manage it remotely. That way you don’t have to grant ssh access and all that entails to each committer.


To add to what Chris has said, you can use gitosis (http://eagain.net/gitweb/?p=gitosis.git) to control who can actually access the repo.

Depending on your usage, you can also use hooks (in the .git/hooks folder) so that your code will automatically be pulled into the server’s filesystem when you push from your local machine. Here’s a popular script for doing that: http://utsl.gen.nz/git/post-update. This won’t be necessary in all cases though.


http://repo.or.cz, while fairly good tends to have some issues with some users.

If you are one of them I recommend that you try out http://unfuddle.com since you come from a subversion background.

Check out “The 30 Second Tour“: http://unfuddle.com/about/tour/plans


http://code.google.com/p/luna-tool/ is scala application which implements most of needed for me parts of github