This happens to our team too.

Does anyone else find it ironic that Git is a distributed version control system, yet we rushed to centralize it and base our entire workflow around GitHub?

I've tinkered with the idea of setting up a git repo on a hosting provider like Digital Ocean for just an occasion. Maybe back it up hourly from github, and/or also push to it regularly by adding it as a remote in our git repos.

Anything business related we use beanstalkapp, for its better price-per-private repo and deployments in any case (no issues with them ever!)

Github is just a node. IF Github dies , people still have the full repos on their computers.That's not always the case with SVN... And most people are too lazy/dont have resources to set up a git server anyway.

The problem isn't developer access to the code, but that GitHub gets tightly linked to other tools, such as continuous integration and test tools. If Jenkins is expecting to pull the latest code from GitHub, but GitHub is down it's a PITA.

There's also stuff like GitHub Issues, which are separate from the actual Git hosting. So even if the source code is available and the 3rd party tools aren't broken, work can still be interrupted.

This is true but it misses the point of Github.

Nobody denies your blobs are safe and available elsewhere when Github goes down.

It's the infrastructure around those blobs that makes Github so popular. It's your issues and pull requests, your wiki, your connection to Travis-CI that are gone when Github goes down.

That is why people get angry when it goes down.

Most teams that work on GitHub have none of their own workflow or infrastructure for sharing code when GH goes down.

You can probably blame those teams for that more than GitHub but people do seem to have bought into the idea that we can just jam everything up to GitHub and get it back later.

Of course from a risk-management perspective, the likelihood of a long term outage is statistically low enough to not justify the expenditure for setting up and maintaining alternative systems (other than simply having repos backed up.) It's the anti-TSA approach. The TSA spends billions and hassles everyone despite the relative rareness of air-travel attacks. But, the severity of a potential attack weighed against the expenditure has led politicians to believe that the cost is worth it.

The Heroku/AWS outages a few years back had far more of an impact, yet Heroku still (to my knowledge) relies exclusively on AWS-East, because presumably the risk-profile doesn't exceed the threshold to justify the expenditures required to mitigate the risk.

I just wish the attackers would be considerate enough to share the schedule for these attacks ahead of time, so I can plan a longer lunch. The rudeness of these attackers is unparalleled. I'm inclined to write them a strongly worded letter suggesting same.

If your workflow involves tickets on github, you're going to have a bad time.

If your workflow involves [thing] on [service], you're going to have a bad time.

What's a "git server?" Set up any machine that can be SSHed into, maybe apt-get install git and you're done. Git is just files.

I always wonder if people prefer to use a centralised model that github seems to promote, or if people are not tooled up to take advantage of the distributed nature of git?

How technically hard is it to have an internal roundrobin git system that's synced up with the github repos needed, and then redirect to the internal git servers as needed when github goes down? I'm just wondering, no snark.

Github will go down by the nature of it being a web service. Web services aren't 100% by nature.

Although, I don't have experience with Gitlab, I did create a screencast about git/gitolite, which can do 90% of what you want @ http://sysadmincasts.com/episodes/11-internal-git-server-wit...

Then look at something like Gitweb [1], cgit [2], or Gerrit [3] to front the repo. I personally use git, gitolite, and gitweb.

[1] https://git.wiki.kernel.org/index.php/Gitweb

[2] http://git.zx2c4.com/cgit/

[3] http://code.google.com/p/gerrit/

I've been very happy with Gitlab. The CI server seems a bit simplistic at this point and I haven't tried it, but I'm slowly moving all of the stuff I need to have more consistent access to, from Github.

GitLab co-founder here. Thanks for commenting druiid. GitLab CI 3.1 will have very nice integration with GitLab 6.0. It will still be simple, but should cover most cases.

Have you tried Jenkins as a CI server? While the core Gitlab product is quite nice, the feedback I've heard on the CI component is that it becomes problematic once builds become non-trivial (though to be fair, I've heard this mostly from Jenkins folks).

We just built our own build scripts (in make(1) like god intended) and wrap jenkins around that. Pretty hard to go wrong with tech that's been tested for the last 35 years

With due respect, God probably had little to do with make.

Who made the make maker?

Science.

We are using Gitlab for about half a year with Jenkins, and we could not be happier. We are about 50 devs working with it every day. It has some quirks (for example AD integration) but it has served us well, and we would not want anything else.

GitLab co-founder here, thanks for the comment y0ghur7_xxx. Please let me know if you have any idea's to improve Active Directory Lightweight Directory Service support.

I used GitLab by myself, it works really well and since V5 is super easy to get installed.

Is there a VM image like Github enterprise?

BitNami keeps up-to-date Gitlab VMs and Installers: http://bitnami.com/stack/gitlab

There is at least one Vagrant+puppet installer I know of but, well, uhhh... it's on Github and won't help you much at this point :P https://github.com/sbadia/puppet-gitlab

Yes, kind of deadlock.. Nice try anyway :)

Git's distributed right?

Started timing out for us mid-deploy.

Not a good situation.

I use Gitboria, accessible through CJDNS.

time to learn peer to peer git pull for your team

man git daemon

man git-daemon #ftfy