Using Git to Interact With Your Fellow Humans

Git has extensive man pages for every aspect of the tool, but they are only reference documentation. They won’t tell you the human story of how to use git to interact with your teammates. I want to teach you how you and your team can get beyond just using git and start helping each other work.

The man pages for git are a technical reference guide for how to accomplish very specific tasks with git. We can all read them and learn how to use the tool, and if you’re working alone, that’s enough because you can keep your later frustrations with your git history to yourself.

Git really shines when you use it to interact with not just your code, but the fellow humans on your team, but only if you know how to go beyond remembering the command, and take that next step into understanding how your choices affect the rest of your team.

There are so many teams out there using git in a frustrating way. Either they are new to git, or they have been using it for a while, but they haven’t had the kind of mentorship that it takes to use it in a way that makes their jobs easier, not harder. Git as a tool is still a thing that these teams spend time wrestling with. But if you think of a really good tool, it should be something that makes your workflow easier, not something that introduces a lot of new friction into your day.

Many people think that reading the man pages over and over again, or looking up forum answers is going to help. But the answers to these kinds of one off technical questions aren’t going to help you with the human problems you’re having.

I want to teach you how to use git to interact with your teammates in a way that answers those human workflow questions. I want to keep the way that you use it as a team front and center. I want to help you answer questions like:

• What should I name my branches?
• Where should I create my branches?
• What is a good commit message?
• When should I do a check in and which remote should I check it into?
• What is squashing commits? Why should I do it?

What people often miss about using git, is that if you aren’t keeping these questions in mind when you are committing code, then it becomes harder to answer the critical questions later, that git is really good at, but only if you help yourselves up front, as a team. Questions like:

• Why was this change made?
  • This one is critical. Most people ask “who made this change?”, but that’s almost never the real question. The real question is why, and git can help.
• I’ve decided this change should be reverted, but what is the change? Which commit(s) do I have to revert to remove it?
• My teammate and I are collaborating on a feature, but how do I know what their progress is? How can I keep up with their changes without the two of use stepping on one another or creating a tangled mess?
• How do I read a git history and make sense of the changes this code has gone through over time.

We can step through some examples together and see what those examples look like in Gitub, Gitlab, and even right on the command line.