Emma Jane Hogbin Westby - Git for Teams: A User-Centered Approach to Creating Efficient Workflows in Git

Beijing Cambridge Farnham Kln Sebastopol Tokyo

For nearly two decades, Ive 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 name of a file to denote a new version. My work space was littered with files with unusual extensions; v4.old-er.bak was an all too common sight. I wasnt 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: Id print out the Perl scripts I was working on, and put the pages into a ring binder. Id then mark up my scripts up 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; 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 theretypically CVS. It wasnt 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 didnt want others to think I was slacking off!

Meanwhile, Id 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 of the teams was forced to use version control to track their work. The students, who had no prior programming experience, werent thrilled with having to use version control as they felt it got in the way of doing work. But it also made it easier as they didnt ever accidentally overwrite their classmates work. It taught me a lot about how to motivate people to use a tool which didnt feel like it was core to the job at hand.

In the decade since that class, Ive 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 Ive 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 youre 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 whove previously used similar techniques.

This book wont 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. Its 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 youll let me know (); and if you find it useful, I hope youll let the world know.

The book takes a people-first approach to version control. I dont start with a history of Git, instead I begin with a 10,000 foot view of how teams can work together. Then we will circle our way into the commands, ensuring you always know the why behind the command youre about to type. Sometimes you can save your future self time (and confusion) by adopting specific routines or work flows. These explanations give you a holistic understanding of how your work today affects your work tomorrowand hopefully make sense out of some of the near-religious insistence by some people on why they use Git the way they do.

The first part of the book will be most useful to managers, technical team leads, chief technology officer, project managers, and technical project managers, who need to outline a work flow for their team.

Good technology comes from great teams. In you will learn about the dynamics of creating a great team. By the end of this chapter you will be able to identify roles within a team; plan highly effective meetings; recognize key phrases from people who are out of sync with what your team needs; and apply strategies which will help you to cultivate empathy and trust within your team.

Set the expectations early for the type of project you are running. In you will learn about different permissions strategies used to grant and deny access to a Git repository. Should team members be allowed to save their work to the repository without a review, or is it more of a trust and be trusted scenario? Both systems have their merits, and youll learn about them in this chapter.

Make the intentions of your work clear. In Git you will separate streams of work with branches. In you will learn how to separate each of the ideas your team is working on through the use of these branches. Of course you will also need to know how to bring these disparate pieces of work into a unified piece of software. This chapter covers some of the more common branching strategies, including GitFlow.

Write the documentation today which will help you work more efficiently tomorrow. In you will see the culmination of all the ideas in (to come). You will learn how to create your own documentation and walk through the process of creating, and deploying a simple software product.

The second part of the book, (to come), will be most useful for developers. This is where, finally!, you will get to learn how all those Git commands are actually supposed to work. If youre impatient, and want to get hands on code, youll do well to start reading at this section, and then once youve completed it, go back and read (to come).

Ground yourself in practical skills. covers the basics of distributed version control. In this chapter you will learn how to create repositories, and track your changes to files locally through commits, branches, and tags.

Learn to recover from your mistakes. allows you to explore history revisionism. In this chapter you will learn how to amend commits, remove commits from your time line, and rebase your work.

Expand your team to be inclusive of others. Now that youre a master of history in your own repository, its time to begin collaborating with others in . In this chapter you will learn how to track remote changes, upload your code to a shared repository, and update your local repository with the updates from others.

Through peer review, share the glory and the responsibility of a job well done. In you will learn about conducting code reviews with your team. You will learn about the process for conducting a code review, as well as the commands for a popular reviewing work flow, along with suggestions on how to customize it for your team.