Are you familiar with git?

If you’re an engineer, it’s very likely for you to hear this question during job interviews. And if you often use GitHub, you would typically feel confident with (g)it. But how much are you familiar with it? In this article, I want to talk about how I learned the basics of git, and how it turned out to not be enough to fit most of the scenarios I faced working in agile teams.

When I started my career as a software engineer, SVN was the first control version tool I’ve been using. SVN is super easy to start with. It has no staging area, and using it feels more or less like you’re exchanging files with some FTP server. It’s simple, and it worked well in teams of 2–3 people I used to be part of. But as I discovered GitHub and started approaching open-source software, I found out that git was more widespread, more loved by the community, and that it solved several problems I didn’t even know SVN had.

To get started with git, I enrolled in a Codecademy course. It was an interactive tutorial, a fun way of learning for beginners like me. At the end of the course, I had learned commands to use staging, remotes, and branching, but I couldn’t really understand the value git can bring to any team.

A few years later, I joined a team where I had the opportunity to test my git knowledge on the battlefield. The team was made up of 4 engineers, and we were working on a web application that would help in the healthcare business. Everyone was more experienced than me, and more often than not I used to bother someone to help me untangle the git mess I had in my head.

Some of the most common problems were:

• I started working on something but haven’t created a feature branch, what do?
• I checked out another branch, why do my changes are still here?
• I pulled the last changes, why is git asking me to merge the code now?
• How can I undo the last commit? What if I pushed it already?

The last one is very common, right? I bet everyone faced it. When you are really a rookie, even reading answers on StackOverflow may not be enough to get a solid understanding of why you came across that issue and how to solve it. You could end up pasting commands that just don’t fit your scenario, leading to a state where you have no idea of where your code is, and how to go back.

After a bunch of mistakes, I was feeling confident with running a fixed number of commands, safe enough to lead me up to the pull-request form:
I’m on the development branch. Okay. Pull the last changes. We’re synced. Cool. Create a branch. Drop some lines of code. Git add. Commit. Push. Submit the PR. Done, yay! If anything would go wrong in this process, I likely knew how to fix it in a way that my pull-request would somehow go through.

Different teams follow different strategies. The great flexibility of git allows us to choose between several flows, depending on which one we feel most comfortable with, or which one is the best for a certain project. When I joined another company a few years later, I had to reset part of my knowledge collected over the past experience because the new team was using a different git flow.

There I learned that:

• Some teams use master as the branch for development, some teams use it to hold the production state of the software.
• Different teams have different naming conventions for branches, some teams don’t even care about branch names.
• Some teams care about history and commit messages, some teams don’t.
• Some teams merge, some teams rebase, some teams squash and merge.

Given the fact that there’s no best git flow, but just a bunch of different opinions, I believe it’s really important for teams to define on README(s) which strategy they do apply so that every developer who’s onboarded can get the chance to read it before making any questions or mistakes.

While working in this new team, I found out that the git commands I’d been using since that point were just not enough to cover for the new scenarios. The team was very dynamic: to make sure the guys won’t spend too much time in code-reviews, it followed the best practice to not make a pull-request bigger than 20 modified files. As a consequence of this rule, it was very common for a developer to open a pull-request for feature X and start working on an X’s sub-feature right away, even before feature X was merged.

The need to survive in such a dynamic environment pushed my git knowledge far away from where I had left it with the previous company. Only after a few months working in teams like that, I started feeling confident with git. Based on my experience, I would consider the use of “git stash” and “git rebase” two milestones that made me drew a step up in my git learning path.
Recently, my manager told me about the -poption of git add, a small tip, but it literally blew my mind. Now, I hardly find a problem that I can’t solve using the git commands I learned so far, but when I do I take it as an opportunity to learn. Today, I’m still learning git. And I don’t think I’ll ever stop.