Git Server Like GitHub?
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.
- Find somewhere to put the repository (
- Create a new repo (
mkdir project.git && cd project.git && git init --bare --shared=group).
- Then on your client, clone the remote repo (
git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
- add some files (
git add README)
- commit (
git commit -m "Initial import"),
- push (
git push origin master)
This should set things up for you.
Read more... Read less...
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.
Bare Bones Browser
git instaweb --httpd=webrick
from the git scm book
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:
git serve. "Ready to rumble," it will report. Git is bad-ass.
- Find out your IP address. Say it's 192.168.1.123.
- 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://192.168.1.123/"
- Press ctrl+c when you don't want to serve that repo any longer.
You could also tell Jane to
git clone git://192.168.1.123/ local-repo-name if she does not yet have a clone of the repository. Or, use
git pull git://192.168.1.123/ 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