ssh-copy-id -i ~/.ssh/id_rsa.pub email@example.com
ssh firstname.lastname@example.org 'cat >> .ssh/authorized-keys' < ~/.ssh/id_rsa.pub
But it's a bad habit to get into. Or better yet, it's better to think in idempotent operations when doing systems work.
When you do this, make sure that the server has continuous backups. Also, make sure you still have an offsite backup.
Once you figure out what these things are worth, you may realize that you should probably just keep paying Github.
There are many other good reasons for a service like Github, like the excellent collaboration features, the really good repository and history browser or the good bugtracker.
If you don't need those (small team, working alone) but are concerned about uploading your intellectual property to a third party server in a potentially foreign country (depending on your location), then quickly setting up gitosis / gitweb / redmine might be enough for you.
In my personal case, I would really love to use github even for my small team, but I'm too concerned about the legal issues to go ahead with that (and the local installation is plain too expensive).
I can't imagine that GitHub would steal your code. They've never heard of you, they have no reason to believe your code is worth anything to them, and one "I have pretty damn good evidence that GitHub stole my code" could ruin their entire business.
You mentioned legal issues. Are you afraid someone's going to ... subpoena your code or something? Because if that happens, you'd have to turn it over anyway.
They've got some pretty intense-looking security, and people like Twitter trust them with their code. If they aren't worried, why are you?
2: I don't know that that's officially known, but I saw Twitter commenting on the "GitHub now has Organizations" post complaining about the lack of the cheaper plan that they added the next day. So they definitely have some private repos on GitHub.
Of course, I could always trust them for now and instantly remove my stuff when there are signs of trouble, but I asked them (a year ago) whether deletions are instant and irreversible and they told me the usual thing: repositories are not instantly deleted so they could restore them in case of accidental deletions. In addition they stay around in backups for an indefinite time.
Legislation not known well enough and no control over the removal of my code from their machines - call me paranoid, but these are good reasons not to upload my code to them.
Not if you don't live in the US.
Might sound unlikely but it happens.
Also, if github is down or your repo with them is corrupted, you have to go through their support. If your own server has a problem you can fix it instantly.
I'm not convinced that reliability is the correct reason to go GitHub. Features: Yes. Reliability: Not necessarily.
Data safety is all about fighting correlation. You don't back up one partition to another on the same spindle, because when the drive dies the whole spindle is lost. Paranoid people back up to two different drives, two different disk controllers, two different machines, two different datacenters, two different continents...
 But nonzero. It is worth thinking about the scenarios.
In addition to the remote repos on Github and my normal local copies...
So github can be a part of a backup strategy but it isn't a strategy by itself.
Likewise, there are plenty of parties that wouldn't dream of storing their data in a third party repository, it could be compromised, there are at least 'n' github employees that now have access to your data etc.
So there is a need for both options, one where you outsource your headache to github and keep a couple of local copies just in case, another where you do have your own repository that you control with the associated backup mechanisms and a number of off-site copies.
Fortunately github makes it easy to do the former and git itself can make it (relatively) easy to do the latter.
For plenty of people the first is enough. For me it wouldn't work, so I'm really happy this got posted.
It runs in cron and backs up all my data daily.
I love GitHub and I'm sure they'll continue to do well, but running your own Git server is only going to get easier. If you don't need the social side of what they offer, hosting yourself makes sense.
mv $ZIP_FILE_NAME $ZIP_FILE_NAME.txt
You can also stick a git repo on top of Dropbox... There are several articles about how to do this if you do a quick google.
Whether or not this makes you "decentralized" depends on where your directories live. Two machines in the same location? Not decentralized.
Given the decentralised nature of Git, having continuous backups becomes less important unless all my computers (including the server) fail at once.
But yes, backups are important, and they are done.
Doing it manually for me just means (on the server):
git init --bare
I already have ssh keys set up from long back, so that's all I have to do really. Then I just add the remote repository on my local machine.
Setting up gitolite is dead simple - setting up a git server manually manually might be 'simple' compared to other tasks, but it's still unnecessary work. Creating new repos is as simple as changing the config file and pushing it - no need to do anything on the server at all.
I see absolutely no reason TO do it manually, and that's the decider.
If anyone is interested, I created a library for deploying git hosting (or SVN hosting if you really prefer) on a VPS with Redmine project management: http://github.com/ericpaulbishop/redcloud
Git hosting is provided via gitosis, not gitolite since there is no redmine plugin for gitolite support. It runs on Ubuntu VPS and uses Nginx with passenger compiled in as the web server. PHP via php-fpm can optionally be compiled in too, in case other sites on the same box need PHP (as is the case for what I'm doing).
If you do want your own private server, VPSs are getting ridiculously cheap. lowendbox.com relays the latest offer of Open VZ 512MB, 20GB of storage, 1TB of bandwidth, all for ... $3.60/month. At those prices, your backup strategy could simply be to have two, or three, from different vendors. These cheap VPS hosts can just disappear one day, so never have this be your only copy of anything.
I like the system, and it's very flexible, but it doesn't seem like they treat it very well for outside use.
I keep private github repos for collaborative projects.
This is a question I've been struggling with for a while now.
Would you host your company's super important bread and butter code on GitHub instead of your own server?
I get a funny feeling every time I think about this mostly because I've put tons of time (3 years) into our code base and I think of it as one of the most important aspects of our company.
Then again, GitHub hosts their code on GitHub which makes me feel a bit at ease in doing so.
I would really appreciate your insights.
Our codebase is GPLed, so there are no concerns about privacy.
This makes sure that the repository works with dumb servers which is required for things like http/cgit.
I am using git because I hate svn (so I use git-svn), so I am curious how a pure git setup would work...
I am sure there are more scenarios but this is just what I could think of in a min.
In fact, I will often "cheat" and read the discussion first.