

Self-hosted Git Server - emilyst
https://www.petekeen.net/self-hosted-git-server

======
jmoiron
I spent years out in the woods with my own projects page that nobody could
find and very few cared about, happily cutting trees down with nary a witness.
I wanted control over backups, presentation, availability. I was terrified of
relying on services that could disappear. I found self promotion distasteful,
and I was happy to do the work just for its own sake, for the enjoyment of
that process.

But then I wrote something people actually used. And they wanted it on
Bitbucket, and then on Github, so they could contribute to it and track its
progress.

Now that I've come in from my Zen training out in the wilderness, I feel that
the old me who wanted "control" over all of my creations was immature and
selfish, abstaining from participation in a community and helping no one but
myself. I think that the social aspect of hosted coding sites, both for
collaboration and exposure, is much more valuable than the control you get
from running the whole show yourself.

~~~
zrail
Honestly, I'm not super concerned about GitHub disappearing in a puff of
octocat ink one day. I know they're around for the long haul and I think
they've done great things for open source.

No, I'm more concerned about branding. If someone comes to my site and I
direct them somewhere else, I lose them. If they stay on my site and browse
around, my site's look and feel is indelibly linked with my code, my projects,
and ultimately me as a professional software developer.

~~~
cnaut
Is branding the biggest reason for hosting your own git server?

~~~
zrail
For me personally, I guess the biggest reason is being able to control the
user's experience, as well as my own. Plus I think it's neat, and it was a fun
project to do on a Sunday afternoon :)

~~~
rgj
You seem to completely misunderstand. People using, forking or contributing to
your projects do not want their user experience to be controlled by you. They
want their own familiar user experience.

Of course it's a fun project, but it's really meta. Wouldn't it be more fun to
work on one of your actual projects ?

------
616c
I checked out this guy's site. I understand he is reinventing the wheel. I
respect that and do not mean anything negative about that. A lot of us are
here to understand the wheel and build for ourselves. There is good value for
that.

What I do not understand, with all due respect, is the value of Github, and to
a lesser extent Bitbucket, is in the features outside of the VCS core and how
most people realize there is nothing Git-like to replace the actual project
management tools where people find Github value. That is, bug tracking/issue
tracking is the killer feature.

To self-host this is problematic. This is not to say there are not good
solutions. Traditionally that is Bugzilla, Trac, Redmine, and more recently a
la ArchLinux and Music Player Daemon (MPD) I have seen Mantis BT. It looks
interesting. The problem is, as others point out, maintenance, and adding the
centralized to the decentralized, thus the point of Git, Mercurial, and
others. I noticed this guy hosts his own repos (I tried links to bugsplat.rb)
and it did not load, but I assume there is not bug tracking, despite the name.

Even this year, I decided to look into the state of DVCS integrated bug
tracking. Very few tools exist, or many have problems. BE, bugseverywhere,
kind of exists and has seen contributions as of last year. Ticgit was forked
to ticgit-ng, but ironically that is a Github project and its bugs are in the
Github issue tracker. There was a very cool Perl project, which seems
abandoned, called SimpleDefects (SD), which also wanted to do distributed bug
tracking. It was going to sync with Github and other issue tracker systems
with decentralizaton, so you could git pull for bugs as well. This one has not
seen updates for years, as I can tell, but might be the coolest of them.

Unfortunately, keeping you whole project decentralized is difficult. I have
begun to look into fossil again, despite what people here say, because it
might be ugly, but no VCS has its own bug tracker or wiki integration, all
written in C. It is the SCM and bug tracker for Sqlite, Tcl, and even for all
of NetBSD packages. The last really surprised me. I think for the little guy,
that is ideal. Monotone might be worth revisiting (I had multiple problems 3
or 4 months ago because it was embedding Lua and they had not come up to the
5.1-5.2 API changes and builds failed; everyone is hard to find), even with
the only data about it is there page and links to snarky Linus Torvalds jokes
about the horror of OO data structures and modern C++ programming for a SCM.

In short, you should know to host your own Git repos (they are designed, with
the native package tools in Git or others) to host simply on a website. It is
best for even the lowest footprint web servers, shared hosting or not.

What git does not have, is the beautiful features that keep people on Github
all day. I really wish distributed bug tracking advanced, but no one is
interested. This topic only comes up when Github is down (or maybe in this
case but Github is having publicity problems today). If people made a good
tool like SD, that has its own bug tracking that syncs well with Github or
(insert hosted SCM here), that would be fantastic. I could be more relaxed,
principally, by relying on such tools.

Back to read the Fossil manual.

~~~
edwintorok
I don't consider Github's issue tracker to be particularly good.

Sure its convenient if you just have a small project and don't want to host an
issue tracker yourself and don't care about the usability of the issue
tracker.

The "killer feature" of the issue tracker is that you don't need to create yet
another login just to report a bug. Chances are you've reported an issue on
github before, or if not you just have to create a user once, that you can use
to report bugs on _any_ github project.

I consider Github's issue tracker to be a _significant_ step backward/in the
wrong direction from Bugzilla for several reasons:

    
    
      * defaults to markdown instead of plain text [1]
    
      * no easy way to attach binary files[2]
    
      * no easy way to attach files[3]
    

At least from a project developer's perspective I find bugzilla much easier to
use (once you get used to it), and has more features.

There are some minor improvements in Github's issue tracker, but none that
would want to make me switch.

[1] Whenever I paste some error message / shell output I need to escape it in
<pre> or <code> blocks, otherwise it messes up the formatting. I initially
created a lot of broken bugreports, that I had to edit once I've seen how bad
it looked, of course then I found out you can _preview_ the bug before
submitting. IMHO text should be the default for bugreports, not markdown!

[2] they come in handy depending on the project. If the project deals with
binary files, it is expected that bugreports may have to contain them as well

[3] Besides creating a gist and pointing to the gist you pretty much have to
self-host any file you want to "attach" to a Github issue, unless I'm missing
something.

~~~
jpiasetz
This is an interesting comment, my work flow is almost completely different. I
wonder if it's a difference based on what language we both spend the majority
of our time in (for me Javascript, python, ruby).

* For markdown I prefer the synatx highlighting and scrollbars that show up on github to the giant blobs plain text gives you.

* I rarely want to attach binary files while I often find myself embedding inline images to illustrate a point

* I use cat test | gist -c -f test.txt -d "Output from failure" (it puts the gist link in my clipboard).

~~~
edwintorok
Majority of my bugreports are related to C/C++ and to some extent OCaml, and
mostly command-line programs. Hence a text-based entry for the bugreport is
more convenient.

------
lholden
The fantastic thing about distributed version control systems like GIT is that
you never actually _have_ to depend on a single repository.

Use Github, Bitbucket, and your own "server" all at once. None have to be
read-only. Push and pull from multiple sources.

Decide that Github is no longer the place for you? No problem! People
contributing to your projects should already know where to push to reach
everywhere it needs to go and they only need to stop pushing to github.

No reason to rely on a "central" repo.

~~~
_frog
Worth noting though, a lot of the value of GitHub in particular, and to a
lesser extent many other services, are extra features like issue trackers,
wikis and so on that act to lock you in.

~~~
lholden
I can certainly see services like wiki and issue tracker hosting being big
value-adds with GitHub. Thankfully GitHub does allow you to export your data.
(And to be honest, I feel it would be a mistake to use these services if you
_couldn 't_ export your data.)

The wiki system on GitHub is based out of it's own git repo
([https://github.com/[user]/[repo].wiki.git](https://github.com/\[user\]/\[repo\].wiki.git)).
If you could be bothered to pull/push when changes are made, I'd imagine this
content could then be made distributed.

While not distributed/decentralized... GitHub does lets you export your
existing issues. The resulting archive can then be imported into services like
bitbucket, pivotal, and etc with a little work.

There _are_ solutions for distributed/decentralized issue tracking, but I
haven't seen any great way for users to interact with them. (SD and Bugs
Everywhere, other users have posted links in their replies.)

------
geerlingguy
Here's another example, using Ansible and a few simple roles from Ansible
Galaxy: [https://github.com/geerlingguy/ansible-vagrant-
examples/tree...](https://github.com/geerlingguy/ansible-vagrant-
examples/tree/master/gitlab)

Give Vagrant + Ansible about 15 minutes, and you'll have a nice little local
GitLab server running. Modify the Ansible playbook slightly, to point it at a
VM on Digital Ocean or elsewhere, and you'll have a nice little hosted copy of
something like GitHub.

I run an instance of GitLab on a Digital Ocean droplet, and back it up to a
cheap RamNode VPS; all my GitHub repos are pulled daily to repos on the GitLab
server (for backup purposes—I use the GitHub repos primarily), and I also use
this GitLab server as a central repo to which I push changes for my
sites/services, and pull from on production servers.

There are many good reasons to put certain repositories on GitHub, and there
are some good reasons to host some repositories yourself (or to just have one
local working copy, with a backup).

~~~
HeyImAlex
I've been playing with this same setup for the last two weeks at work. I've
got our full dev server config in ansible and stored in a repo that has a post
receive hook that self-runs the playbook, and an instance of git lab running
in a container and routed via nginx.

Gitolite is pretty robust, but after setting it up I kept on thinking of
features I would like or need and I realized I was just rewriting git lab :)
there are some docker images that make setting it up cake, and a full
installer available for centos and Ubuntu.

Also I think I've used some of your roles off galaxy :) thanks for writing
them haha

------
tenfingers
I also use my private repositories (simply setup using gitolite), but I simply
also push to GitHub for the added discoverability.

I tend not to like GitHub however. The wiki/issue tracker actually require you
to be online, which is the best thing about git: being able to work without
network connection.

I'd like to find some project that syncs github issues with sd
([http://syncwith.us/sd/](http://syncwith.us/sd/)) or bugseverywhere
([http://www.bugseverywhere.org/](http://www.bugseverywhere.org/)), so that I
could actually work on the issues without being online (the bigger pain point
are attachments which need to be downloaded).

Another thing which I consider inferior to patches by mail are pull requests.
Honestly, it's very rare that I can accept a patch without some reformatting
or minor corrections. I also never ask people to do such minor reformatting
just to be able to click 'accept'. Again, pull requests cannot be worked-on or
accepted offline. Similarly, my patches sent to other projects are similarly
handled by other authors.

~~~
beagle3
Fwiw, pull requests are merely branches im the repository (named pr-* if i'm
not mistaken)

------
taylorlapeyre
An elegant solution for you, no doubt.

However, I couldn't part with the excellent tools that GitHub has developed
(and will continue to develop) over the years.

~~~
michaelmior
I still use GitHub quite a lot, but I've started using a private installation
of GitLab[1] for private projects and I quite love it. So far, I've only been
using it for myself, so I'll admit I haven't really touched the collaborative
features, but it does seem to have a lot of the nice features from GitHub.

[https://www.gitlab.com/](https://www.gitlab.com/)

~~~
zrail
Yeah, GitLab is great. I wanted a quick solution without many dependencies
that would also act as a portfolio, so I went with a custom thing. GitLab is
definitely something to consider.

~~~
neumann
I use GitLab at work, but for home, the amazing GitBucket does the trick and
took a total of 30 seconds to install
[https://github.com/takezoe/gitbucket](https://github.com/takezoe/gitbucket)

~~~
sytse
If you want to setup GitLab quickly please check out the packages
[https://www.gitlab.com/downloads/](https://www.gitlab.com/downloads/) (I'm a
co-founder of GitLab.com)

------
szhu
It looks there are two main reasons to have a private Git server: to archive
your own code, and to have control over how visitors and collaborators view
your shared code.

If you want a place to store or archive personal projects (because you don't
want to pay for private Git hosting?) features like wikis and issues become
rather irrelevant, and if you want to move that data to or from GitHub, that
takes some effort to be explicitly exported instead of just adding a new
remote.

If you're trying to keep your own code, running your own Git server is simple
if you have SSH (or not even SSH if you want to create a local "server"). The
Git website has a simple tutorial for this: [http://git-scm.com/book/en/Git-
on-the-Server-Setting-Up-the-...](http://git-scm.com/book/en/Git-on-the-
Server-Setting-Up-the-Server)

I've also simplified this workflow into a tiny command, "mygit":
[https://github.com/interestinglythere/mygit](https://github.com/interestinglythere/mygit)

As for running a GitHub clone, unless you have some really edge-case needs or
you really don't want to pay for private collaborative repos, your time is
probably better spent maintaining your actual code. In addition, having your
code on a social site will make it more receptive to contributors. If you
don't want contributors, why do you need a /Git/ server? (If it's because
that's how you like to manage your code, see my first point.)

------
Nux
Also check
[https://github.com/takezoe/gitbucket](https://github.com/takezoe/gitbucket)
Installation is as easy as downloading it and running:

java -jar gitbucket.war

~~~
stefan_kendall3
Disingenuous. What happens when you need to restart your server because of
some extreme necessary security patch?

How do you manage backups?

Since it's running on java, you probably don't want to expose this server to
the internet unless you actively want to maintain updates to JDK versions. So
now you're on the hook for that.

Self-hosting is never "simple".

~~~
sdesol
"Since it's running on java, you probably don't want to expose this server to
the internet"

Is latest versions from tomcat/jetty/etc. really known for having major
security holes? More so than apache/nginx/etc.

Maybe you are confusing the recent Java applets security issue with Java in
general. Java has got to be one of the most well funded and developed
technology out there, due to peoples reliance to it in enterprise.

People also don't normally run their Java web server as root which adds a bit
more security. If there is something about Java security that makes you so
worried, I would love to hear about it. As it will probably be news to me.

~~~
stefan_kendall3
Some of the exploits that target applets also affect running servers. Tomcat
or Jetty or WebLogic from two years ago are likely compromisable pretty
easily.

Any web server has the same issue, and most people are more than fine if they
update somewhat regularly. Whether node or rails or whathaveyou, you need to
keep updating.

My code on github from two years ago is as secure now as it was then, because
someone else has taken on the onus of playing security-update wack-a-mole for
me. That's all I meant; I didn't mean to imply java was less secure by default
than any other thing listening for connections on the internet.

~~~
sdesol
"Some of the exploits that target applets also affect running servers."

This would make sense. It's the same reason why php makes apache or ngnix
insecure. They are front facing and have access to the OS filesystem and such.

"I didn't mean to imply java was less secure by default"

Okay gotcha. I work with Java quite a bit and was confused by your statement
as I thought I missed some major security news.

------
hipaulshi
Well. I have to be honest. I used to do just that. And it is not fun to worry
about backups and server breaking down. Outsourcing this part to Github will
probably save a lot of developer/IT headache if you are a small company.

------
mixologic
What about all the problems that are inherent to hosting _anything_ ? It's not
hard to set up a server that will respond to a request and deliver data.

It's hard to make it do that when the power goes out, when you anger somebody
and they decide to ddos you, or when your code/service/whatever becomes
insanely popular and whatever mac mini you run it on is overheating. It's hard
to keep up with all the security patches required to keep your box from
getting pwned. It's hard to negotiate the fine print with all the TOS's you've
signed with your internet provider.

~~~
zrail
I'm sorry, I should have clarified. My private repos are running on a VM in
the living room, but the public-facing website and repos are all on a Digital
Ocean VPS.

------
aleprok
I have registered in January 27 2009 to github, but I have been running my own
git repository on a dedicated server for quite some time. I have never really
been active at github or any other third party repository service. The reason
I want to self manage my hosting is that I can get cheaper private
repositories.

------
sqrt17
For private repositories, I've discovered a software called SCM Server. It
lets you add different users, with passwords, and create SVN/Hg/Git
repositories with each their own access list.

------
zrail
Sorry about the occasional 502s. I added a smattering of caching to the
project pages so it should be better now.

~~~
stefan_kendall3
This is my point exactly. Self hosting is maintenance. In the time you got
502s, my github pages stayed up. It is grossly inefficient to host your own
source control.

Libraries and third party services exist for a reason.

~~~
zrail
Life is built of tradeoffs and compromises. For you, github pages makes total
sense. For me, not so much. Saying that my little VPS is "grossly inefficient"
compared to your GitHub repositories is like comparing apples to... I dunno,
like a rock? or a monkey? Something else entirely, that's for sure.

~~~
camus2
It only proves you did not build your solution with scalability in mind. Once
you get more traffic and the hosting bill goes up, i'm pretty sure you'll
reconsider self hosting for the sake of self hosting.

~~~
zrail
The page in the original post has received 16,000 pageviews in the last 12
hours. Admittedly the project pages were not performing very well initially
but after I added caching they haven't even blinked, and the dual core VPS
(which runs a dozen other services besides this) is ticking along at a load
average of 0.63.

Tell me again how I didn't design for scalability. I'd also love to hear your
definition of "more traffic".

------
rsgalloway
heh, what at the odds: two libs that give you object-oriented access to git
repos both coincidentally named the exact same thing:

python: github.com/rsgalloway/grit ruby: github.com/mojombo/grit

