Git for Teams

Preface

For nearly two decades, I’ve been working on teams of one or more in a distributed fashion. My first paid job as a web developer was in the mid-’90s. At the time, I maintained versions of my files by simply changing the names to denote a new version. My workspace was littered with files that had unusual extensions; v4.old-er.bak was an all too common sight. I wasn’t able to easily track my work. On one project, which was a particularly challenging one for me, I resorted to the copyediting techniques I used for my essays: I’d print out the Perl scripts I was working on, and put the pages into a ring binder. I’d then mark up my scripts with different colors of pen and transcribe the changes back into my text editor. (I wish I had photos to share.) I tracked versions by flipping through the binder to find previous versions of the script. I had no idea how to set up an actual version control system (VCS), but I was obsessive about not losing good work if a refactoring failed.

When I started working with other developers, either for open source projects or client work, I was never the first developer on the scene and there was always some kind of version control in place by the time I got there—typically Concurrent Versions System (CVS). It wasn’t the easiest thing to use, but compared to my ring binder of changes, it was definitely more scalable for the distributed teams that I worked with. Very quickly I came to value the commit messages, and the ease of being able to review ...