Nerd alert! I need to put this list of instructions for using git somewhere so it’s going here. I hope it might be useful for someone else too.
Why: One of my most valuable assets at my job is a directory full of sample code projects I’ve created over the years. Sometimes, it’s a command line tool such as “nsdictionary” which I created to test something with that API, or sometimes it’ll be a full App like “ThreadedQCLayersAndBindings” which tests complicated interrelationships. They were quick and dirty, taught me something specific, and useful as templates for future exploration and now I can’t bare to lose them.
As with any set of files, there’s two main concerns: backup and synchronization. Backup is really two parts
- If the hard drive fails I want to have stuff stored on another disk.
- If I change a project by experimenting and that experiment fails, I want to be able to revert changes quickly and easily across all files.
Synchronization just means I want to have my desktop and laptop in sync.
There are lots of tools that could work… Rsync, svn, cvs, rcs, etc. Each have their merits, but in the end take too much time to maintain or don’t provide enough features to be worth the time to set up.
Then I heard glowing reviews about Git and how it’s a distributed version control system. So I gave it a shot. Here’s a mini tutorial, if everything you’ve read (or skimmed) sounds good:
: Mac Desktop and Mac Laptop and I mount the HD of one on the other over AFP. This is NOT a tutorial for setting up a git server. There may be plenty of those but that’s more than I wanted to accomplish so I didn’t even read them. Git is installed by default on Snow Leopard so this is also NOT a tutorial for setting up Git on Mac OS X. This is glorified Rsync with revisions.
1.) Create a Git repository for revisioned files
git add -a
Yep, it’s really that easy to set up git. At this point, you can track history through the log of commit messages, and roll back as necessary.
2.) Mount the LaptopHD over afp:// by browsing in Finder, or whatever you’re used to. This also probably works for iDisk and other transport types but for now, we’ll call it LaptopHD.
3.) Clone the repository of tests to the mounted drive
git clone /Volumes/DesktopHD/Sources/tests tests
Wow that’s pretty easy too.
4.) Add the tests I’ve already created on the Laptop to the repository
cp -r /Volumes/LaptopHD/Sources/old_tests/* /Volumes/LaptopHD/Sources/tests
git add -a
Woo I’m invincible!
5.) Then I wanted to push the new files back to the desktop (remember right now I’m at /Volumes/LaptopHD/Sources)
git push ##Don’t do this
What the… NOOOOO!!!!!! What have I done!?!?
Only use git push if you are smarter than me, which isn’t possible so just don’t. The designers put this in by mistake and it’s really horrible (I’m just being inflammatory now so somebody will come along and correct me. That’s how the internet works; I don’t question it.)
First, the correct thing to do in a setup like mine:
5.) Go back to each place that’s out of date and pull the changes back
git pull /Volumes/LaptopHD/Sources/tests/.git
Now the reason git push sucks:
When I did git push, I went back to DesktopHD expecting the files to be there. They weren’t so I did a git pull. Nope, files are up to date. I did a git status on the LaptopHD version, everything was checked in. Back on the DesktopHD version I did git status and all my files were in the status and marked for deletion. What??? So I killed that repository, started from scratch by copying files from the LaptopHD and did all the steps again, except with the second step 5 rather than the first.
Searching online, it looks like maybe there’s a way to set up a –bare repository and use hooks to automatically forward to your main repository or something. Crap on that. It’s easier to understand, “This is a distributed versioning system, you always pull your changes from elsewhere” and with a couple git remote add commands, pulling from multiple sources is pretty painless.
So there’s my story. I really like git now, just so long as I don’t use git push ever.