Not so much particular to git, but a nice property of distributed source control systems is that every participant has a copy of the entire repository. While it may sound inefficient, copying the repository is a one-time cost, and at times like these where one’s central server gets hacked, reimaged, and otherwise lost, it’s handy.
Strictly speaking, git doesn’t have a central repository, but I use an account on my server where I push the changes from where I’m working to. After my server was hacked, I could’ve copied from the backup, but it was more interesting to get it from the clients.
My normal workflow on my workstation is:
- Make edits.
git-committo commit the changes to my local copy of the repository.git-pushto push all the new changesets to my server.
I use SSH as the transport, and SSH keys to avoid the use of passwords.
To recover:
git-initto create an empty repository on my server.git-pushto push all the changesets to my server again.
The first time I tried to recover I pulled it off a workstation with a much older copy of the repository, inadvertently simulating the scenario where different workstations have different, non-intersecting sets of changes. No problem. I repeated the same steps against my laptop, and got the rest of the changes. Since git stores everything as changesets and thinks of branches in a first-class way, there was no opportunity for conflicts.
