What to know before transitioning your team to Git

When Emma Jane Hogbin Westby is into something, she's all in, and then she shares what she learns. For example, she doesn't just use Drupal, she wrote a couple of books about learning Drupal, and she created—and shared—a knitting pattern for Drupal socks. Using Drupal is how Emma Jane got started using Git. Then she wrote a book about using Git for Teams, created an O'Reilly video about Collaborating with Git, and, like she did with Drupal, she speaks about the open source project at tech events.

In this interview, I caught up with Emma Jane before her upcoming OSCON talk and training and asked her about learning Git and using it with teams.

How and why did you start using Git?

It would have been around the time that Drupal was first deciding which version control system to switch to—this would have been 2008, or 2009. (We were using CVS at the time.) As an Ubuntu contributor, my first distributed version control system was Bazaar, so I was providing that perspective into the Drupal debate.

Tell me three things to love about Git, and three things Git gets all wrong.

Things I love:

1. The core community. Not everyone who uses Git is welcoming and encouraging, so Git can seem like a really scary place. I had the pleasure of attending a core contributor conference, Git Merge, earlier this year. The community was incredibly welcoming and very supportive. I'm on the core mailing list now.
2. Rebasing. This command allows me to re-write my local commit history before sharing a branch with others. When I re-write history, I can structure the commits so that my work is grouped into logical units, instead of the series of commits being like a stop animation movie of how I worked.
3. The flexibility. Git may have originally been used for kernel development, but the software is flexible enough that it can be used by almost anyone who wants to track changes to files over time. It remains a low-level tool, encouraging others to build on top of it.

Things Git gets all wrong:

1. Documentation. A lot of the Git documentation is very, very good. But it feels inconsistent because not all commands listed in git help -a have a corresponding manual page.
2. Rebasing. It's a great command that deals really well with the crafting of custom histories and keeping branches up-to-date in a neat and tidy way; however, it just ends up feeling like history revisionism.
3. The flexibility. Git doesn't give a lot of clues about how it should be used. As a result, people can become stubborn about their way of doing things; and because it doesn't really matter, it can cause tensions between developers.

You say that your Git for Teams talk isn't just a tutorial on how to run Git from the command line—it's a workflow overhaul. How will Git help improve a team's workflow?

Git is incredibly flexible, so on its own, it won't be of much help in choosing how your team wants to work together. This workshop is designed to get teams thinking about how they *want* to work together. Should QA have final sign-off? Should everyone be writing into the same repository? Are there regulatory audits that you need to comply with?

These are the hard questions I help people map out in the workshop. Once people have a map of how they want to work with one another, and what their "political" constraints are, it becomes much, much easier to map the relevant Git commands onto your work flow diagrams.

Are there any teams who should avoid using Git because it will only make their workflows worse?

Teams who are very happy with their existing revision control system, and who are working with software that has good community, or vendor support, are probably not in a good position to switch to Git. Retooling your workflow is hard, so if things are working perfectly, I don't think it's worth the startup costs to switch "just because".

What are a couple of the common mistakes you see team leaders do when implementing a Git work flow strategy for a new project?

The common mistakes I see when implementing a Git workflow, actually have nothing to do with Git... but Git ends up getting blamed because of these underlying causes.

"I don't understand!" is often shorthand for there not being a clear map between how the people interact on a team via their code. You can mitigate this problem by talking to your team about how they'd ideally like to work, and then working with them to map Git commands onto the team's desired workflow. Yes, there are a few common conventions (GitFlow, GitHub Flow, Agile Git, etc), and your team may end up using one of them as conventions are often built on good practices for many teams. Too often people forget part of the team and just dive into an arbitrary set of rules. Think about your entire team: from design to deployment—and don't forget QA and security! Talk to everyone and find out how they want to get involved with the code, and if there are any regulatory requirements that will affect how you push code through the pipeline.

"How does this work?" or sometimes "Ugh! This commit history is a mess!" This is a shorthand for people using Git inconsistently because of a lack of documentation. Managers and teams need to insist on having up-to-date, readily available documentation on how the workflow works (including copy-paste-able Git commands). We don't do nearly enough to support our future selves, and onboard new hires. By having that documentation, you can ensure there's exactly one way that the team uses Git. Consistency is really important if you want to have predictable information when you're using advanced debugging techniques. (Un)fortunately Git core won't help you to enforce that consistency.

"..." silence is the worst! I think we need to spend more time talking to people about how we actually use Git through one-on-one conversations. Sometimes it can be nerve wracking to admit you don't know how to do something to your entire team. We need to make sure people are given regular—ideally, scheduled—ways to ask questions, and to share what they've learned with others. Tips and tricks could be compiled into the documentation, and points of confusion can be used to clarify the written instructions.

Which free online resources would you recommend for people who are new to Git and need to master basics before diving into your O'Reilly Collaborating with Git video and Git for Teams book.

• Resources: I've got an ever-growing list of top-notch resources. It's sorted by categories such as Team Governance, Commit Messages, Visualizing Git, Merge vs. Rebase, and more. I try to provide a balanced list of well thought-out resources that I think will be useful to people.
• News: If you're interested in following Git development (and you should—it's a lot more active than I'd originally realized), git.github.io is a new site that has a monthly summary of what's upcoming in new releases of Git and some of the more interesting community initiatives.
• Tips and Tricks: @bestgit on Twitter has excellent daily tips.

This article is part of the Speaker Interview Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon..