I first attempted to use Git almost a year ago. I tried to use it as a kind of rsync’er between computers for my personal projects+data folder. It didn’t work too well: I think it was primarily built with the idea of versioning and syncing source files, not thousands of WAV sample files scattered around thousands of nested folders. So I left “Start using Git” in my to-do list and almost forgot about it.
Recently I was about to start a project where I didn’t know quite well what direction it was going to take. So I was there, experimenting and hacking code here and there while investigating where would it bring us, when I realised that I would like to have a snapshot of the code at that point, before continuing with the next part. The classic solution would have been to make a .zip of the code folder, or a copy of the folder in the above directory, and continue. But if you want to compare between versions, manually calling diff between file versions is cumbersome. I didn’t want to add the code to the subversion repository because it was by no means ready yet for anything. So I though: why don’t I use git for this?
First steps were a bit uncertain, but I quickly developed a simple yet effective command line technique. Yeah, no IDE plug-in whatsoever, I am just using a bash terminal. It works pretty much like this:
- code code code
- looks good! let’s store this…
- git add file1.cpp file2.cpp ………. or git add . for adding all changed files to the commit
- git commit (so that I can enter more than one line of commit message, in the editor that shows up) or git commit -m ‘commit message’ for one liners.
Sometimes, when I want to see what has changed, I use gitk. It is admittedly ugly but once you get it, it’s nicer than reading plain diff output in a terminal screen. Specially because you can navigate between changes, instead of having to manually invoke diff for each file you want to compare.
At a certain point I wanted to make a huge code change, so I made a new branch. Actually, I haven’t gone back to the other branch since then, but it’s good to know it’s there in case I want to see how the code is in that totally incompatible code and class-wise approach to the problem.
Probably one of the things I like more is that everything is lightning fast. Since the repository is stored locally, there is no more waiting for commits to finish or contacting the server for getting a diff. Even if your Subversion server is in your local network, it will never beat the experience of a localhost, direct disk access based repository. This way, one doesn’t get distracted with the check in/commit process; it becomes an almost automatic action so the mind can be focused in the real problem: the code!
If you’re an advanced git user, you might have already realised that I am only using a very reduced set of git features. Whether that’s sad or not, I leave it up to you; I just wanted to highlight the notion that although git is generally used (or was designed) for huge projects with lots of collaborators branching and merging intensively and all that, it is actually very good for producing what I call code sketches, and it doesn’t need to be used by several users with all the clone, pull, push and rest of single-worded verbs paraphernalia to enjoy its power.
Please don’t understand this post as a subversion sucks, use git
square-headed litany, but rather as a friendly git could be quite useful, if you have some spare time you might consider having a look at it
suggestion from a long-time Subversion user who knows Git is intimidating but worth the effort to learn :D
