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 the work others were doing. It motivated me to watch others commit their work to the repository. I didn’t want others to think I was slacking off!

Meanwhile, I’d been teaching web development at a couple of different community colleges. In 2004, I had my first opportunity to teach version control in a year-long program designed by Bernie Monette, at Humber College. The class was split into several groups. In the first semester, the students sketched out a development plan for a website. In the second semester, the teams were mixed up, and the new teams were asked to build the site described by the previous team. In the third and final semester, the groups were shuffled again, and the final task was to do bug fixing and quality assurance on the built site. Each team was forced to use version control to track their work. The students, who had no prior programming experience, weren’t thrilled with having to use version control because they felt it got in the way of doing work. But it also made it easier because they never accidentally overwrote their classmates’ work. It taught me a lot about how to motivate people to use a tool that didn’t feel like it was core to the job at hand.

In the decade since that class, I’ve learned a lot about how to teach version control, and a lot about best practices in adult education. This book is the culmination of what I’ve learned about how to work efficiently with others when using version control. I encourage you throughout the book to do whatever is best for your team. There are no Git police who will show up at your door and tell you “you’re doing it wrong.” That said, wherever I can, I explain to you “the Git way” of doing things so that you have some guidance on where you might want to start with your team, or what you might want to grow into. Using “common” ways of working will help you onboard others who’ve previously used similar techniques.

This book won’t be for everyone. This book is for people who love to plan a route, and then follow the clearly defined road ahead. My hope is that, if nothing else, this book helps to fill the gaps that have been missing in Git resources to date. It’s not so much a manual for the software as a manual for how teams collaborate. If your team of one (or more) finds bits of this book confusing, I hope you’ll let me know ([e-mail]); and if you find it useful, I hope you’ll let the world know.

Acknowledgments

Several years ago, in a little bar off the side of a graveyard in Prague, Carl Wiedemann indulged my questions about Git. Thank you, Carl. Your enthusiasm motivated me to convert my frustration with Git into resources to help others avoid the painful process I’d experienced when learning Git.

I had the wonderful fortune to work with Joe Shindelar at my first job-job after a decade of self-employment. Joe, your passion for excellence has raised the bar for my own work. I am grateful for your patience and leadership. This book was born out of the conversations we had about leadership, team structures, and the Git documentation we created for the Drupalize.Me team. Thank you.

O’Reilly found the excellent Christophe Portneuve to serve as one of my tech reviewers. Christophe, thank you for your patience as I worked through the first few chapters. Your feedback was invaluable. I am grateful for the conversation we had at Git Merge, which helped me to clarify the concepts I use in this book—I had lofty goals of transforming the way people learn Git. I hope this book has become a resource you will be proud to have been a part of.

Bernie Monette, Martin Poole, Drew McLelland: you gave me a platform to refine my understanding of version control through your own projects.

Lorna Jane Mitchell, your cheerleading is tireless. Thank you for sharing your own work on Git. It has inspired me to raise the bar even higher.

Much of this book was fueled by 200 Degrees Coffee, a Nottingham-based roaster. My beverage of choice is a flat white served from 200 Degrees Café, or Divine Coffee at the Galleries of Justice. Thanks for providing an escape and letting me stay as long as I needed to.

To the O’Reilly family: you have been superb at handling all of my requests (and missed deadlines). Thank you Rachel, Heather, Robert, Colleen, Brian, Josh, Rebecca, Kim, and the countless others who worked behind the scenes to make this book happen.

To the core Git community: thank you for welcoming me with open arms at Git Merge in 2015. You embraced my rant from the stage about exploring new ways of teaching Git. You took my suggestions to heart, and made improvements to the Git experience. I am looking forward to participating more in the wonderful community you have been quietly nurturing.

Thank you also to my community of reviewers: Diane Tani, Novella Chiechi, Amy Brown, Blake Winton, Stuart Langridge, Stewart Russell, Dave Hammond, John Wynstra, Chris Tankersley, Mike Anello, Piotr Sipika, Nancy Deschenes, Robert Day, Dave Hammond, Sébastien Simard, Tobias Hiep, Nick Gard, Christopher Maneu, Johannes Schindelin, Edward Thomson, matt j. sorenson, Douwe Maan, Sytse Sijbrandij, Rob Allen, Steven Pears, Laura Lemay. Your feedback was invaluable.

To my partner, James Westby: thank you for patiently waiting as I finish just one last thing. This book would not exist without your support and encouragement.