We’re creeping into Week 4, a.k.a. Finals Week, for my first official pair of Advanced Server-Side Scripting and Advanced Database Structures classes—ASL and ADB, respectively. It turns out that one thing has made classes far easier than I would have ever hoped for:
Git is revision/source control on speed. Git has vastly simplified how the class works together, and has been a major player in allowing us to move as far as we have as fast as we have.
To be fair, we’re not just using Git. The entire suite we’re using consists of:
- Git: version control
- gitosis: Git configuration made fast, easy, secure, and idiot-proof
- GitX: pretty Mac GUI for Git
- JGit/EGit: Eclipse integration for Git
- cgit: Web front-end for Git repositories
We use Git extensively in both classes as our exclusive solution for moving files around—no FTP, no SSH, no WebDAV, nada. I even make my slides for each class available as a repository—when the students want the latest version they just git pull for them. Publishing content to the development website is similarly just a git push away.
Even the database class has benefited from the use of Git. When the students are working on a tricky series of queries, they can break it up into pieces, generate mySQL table dumps, and push the dumps into the repo to share them with the other students.
Another great thing about using Git is merge conflicts. No, really! The students will generate several each night, then have to figure out how to resolve them. This is great, because it makes them communicate about their work. If we were using a client-server source control solution, the students would be locking and unlocking files, ignoring each other’s work and focusing on the locks.
When I planned the curriculum, I included a few slides about Git command-line but focused on using Git from within CFEclipse. It turns out that the students are far more comfortable using Git from Terminal than CFEclipse. I don’t have a solid reason why, but if I had to guess I would assume because using Git in CFEclipse involves going through the Team interface, which puts a clunky layer on top of Git. The students continue to express how much they love Git and how much work it saves them, so I guess the Team interface just isn’t what they’re looking for.
One of the favorite student pastimes with Git is going in at the end of the night and looking at the twisty codeline graphics that GitX produces:
As a teacher, Git allows me to see who is doing what work on group projects, increasing visibility of where individual students might need help. It also provides a nice, clean way of submitting assignments: push to the repo, and any commits after the cutoff time are ignored. Distributing tests has been a breeze: prepare a repo with the test material, then commit, push, and have the students pull to start the test.
For the past couple of years, I’ve been the sole web guy at each company I’ve worked for. I’ve set up Subversion repos at each, trying to keep myself in the habit of using them, but it’s been a rough habit to keep up with. Now that I’m back in a team environment again, I can’t imagine trying to do all of this without Git. If your company has more than one coder and you aren’t using Git, you could stand to take a look at it.
(Those of you in the know about Git may notice that I’ve said “the repo”. We do use Git in a less distributed manner than it was intended, pushing to a central repo on a school server. This is primarily because I want an official place to turn in assignments without having to pull from each student’s laptop, but also because the dynamic-IP nature of the LAN would make this trickier than is worth it. Even with dynamic DNS services.)