If you’re writing code, there is no excuse for not using a VCS. Even as a single developer, even if no-one else ever gets involved, and even if you’re the most organized person on the planet. An organized developer? Hah! :)
Life without a VCS looks like this:
- let’s write some code – great, it works!
- let’s try out something more difficult now
- drat, didn’t work, I hope my editor undo buffer lets me back out
- let’s make a copy of what worked before
- now let’s write some more code – great, it works!
- … time passes …
- time to write code again – hm, I messed up
- where was that copy I made earlier, again?
- drat, it doesn’t have my latest changes
- do I remember which part worked, and what I added?
- … time passes …
- I want to continue on that first attempt again
- hmm, guess I’ll start from scratch
- no wait, let’s make a copy before I mess up
- … time passes, the disk fills with copies, none of them work …
Now let’s revisit that with a VCS:
- write some code, check it in – add a brief comment
- try out something more difficult now
- check it in, let’s add a note that it’s still experimental
- hm, can’t seem to get it to work
- oh, well, I’ll go back to the previous version – easy!
- writing more code, having fun, we’re on a roll
- let’s check it in right away
- … disaster strikes, my laptop breaks down
- get it fixed or get a new one, check out from GitHub
- where was I? oh yes, got one good version and two bad ones
- let’s switch to that failed attempt again
- wait, let’s first merge the latest good changes in!
- cool, now I’ve got an up-to-date set of files to work on
- oh, darn, still can’t make it work, let’s save it with a note
- … time passes …
- ok, time to review the different attempts and take it from there
Note that there are no more copies of files. Only a repository (on your laptop and on GitHub – but you still need to back it up, like everything else). The repository contains the entire history of all the changes, including notes, backing out steps, merges, everything.
A lot of this is possible with any modern VCS, including the “subversion” setup I’ve been using until now. But GitHub makes it effortless, and throws in a lot of nice extras. You still need a “git” application on your laptop (there are several versions), and if you’re using a Mac, you can use GitHub’s own app to communicate with GitHub without having to go through a browser.
Here’s what a “diff” looks like, i.e. a comparison of the source code, showing only the differences:
One line was replaced, two more lines were added at the end. It’s totally obvious, right?
Here’s a history of the “commits” made, i.e. the times when a new version was sent to git and GitHub:
Almost everything is a link – you can compare versions, find out what else was changed at the same time, see what else any of the developers is working on, and of course download a full copy of any version you want.
The other mechanism I’d like to describe is branching and merging. That change shown above was not made by me but by “Vliegendehuiskat” (hello, Jasper :) – and the way it works is quite neat, if you’ve never seen collaboration via VCS in action.
What Jasper did, was create a “fork” of JeeLib, i.e. a personal copy which knows exactly where it came from, when, and from which version of which files. And then he made a small change (without even telling me!), and at some point decided that it would be a good idea to get this change back into the official JeeLib code. So he submitted a “pull request”, i.e. a request for me to pull his changed version back in:
This generated a new entry in GitHub’s issue tracker and an email to me. I liked his change and with one click, merged it back in. Only thing left to do was to “pull” those changes to my laptop copy as well.
GitHub has a graphical “network” view to display all commits, forks, branches, and merges:
Each dot is a commit. The black line is my code, the blue diversion shows Jasper’s fork, his commit, and my merge. Hovering over any of these dots will show exactly what happened.
This illustrates the simplest possible case of GitHub for collaboration. If you want to see how a entire team puts git and GitHub at the center of a large-scale collaborative software development effort, read this article by Scott Chacon (who works with and at GitHub, BTW).
I’ve been moving lots of stuff to GitHub these past few days, not all of it related to JeeLabs. Here are the three main projects, as far as physical computing goes:
Note another nice feature: you can instantly see how active a project is. JeeLib is the brand new combination of the Ports and RF12 libraries, while EtherCard and GLCDlib have been around a bit longer (and the full change history has been imported). It’s been over half a year since Steve and I worked on GLCDlib, as you can see – with a small blip before the summer, when I added font support.
There are a few features which I haven’t enabled at GitHub. One of them is their wiki – because having yet another spot on the web with pages related to JeeLabs would probably do more harm than good. The Café at http://jeelabs.net is as before the place to look for documentation. There are ways to merge this stuff, so maybe I’ll go there one day.
A warning: the “sketches” on GitHub have all been adjusted for the new upcoming Arduino 1.0 IDE, and do not work with Arduino 0022, which is still the main version today. So I’m slightly ahead of the game with this stuff.
I’m really looking forward to how the software will evolve – and you’re cordially invited to be part of it :)
PS. I’m updating to GitHub fairly often because I work on two different machines – and this is the easiest and safest way to keep stuff in sync.