Congratulations Software Engineer II. You Can Push to Origin

Every developer needs to use Git, more or less.

So it’s not surprising at interview you might well be asked the fateful question “Do you have experience with Git”. Professional software developers will instantly answer “Yes, of course”.

The issue is that lack of quantification. What does yes mean?

The Three Sacred Commands

If you’ve mastered source control you know these three commands.

To some, that’s it. You’ve mastered source control. You are now an elite software engineer, a version control grandmaster, the Linus Torvalds of your team.

It’s all fine until something happens. It will, and Git will humble you. It’s going to happen, and how you deal with the issue will expose your actual expertise in source control.

The False Sense of Security

Each day I wake up and go to work I feel the same. I feel secure that everything is fine. Then, every day, suddenly everything is not fine.

It might be my misunderstanding of a bug in production. It might be a meeting with my boss about a target I’ve failed to hit. Sometimes it’s source control.

Most of the time my Git knowledge is enough to get by. Suddenly I’m caught in a merge conflict hell. I suddenly feel that the terminal isn’t enough and move to SourceTree. I move to a Google tab and desperately search for a solution. I have a conversation with ChatGPT about cryptic messages that I can’t comprehend.

I don’t know if I’ve finished my rebase. I seem to have conflicts with my own branch — which happened when kept trying to merge from main in one of my early jobs (that obviously ended badly for me).

It’s at the moment of panic that the commit-and-pushers are separated from actual Git users. The users know if they’re typing a command whether it is likely to make the problem better or worse.

A Day in Git Purgatory

Let’s play out a typical developer’s journey through Git.

1. Make a change.

2. git add .

3. git commit -m “fixing something”

4. git push

5. Error.

6. Panic.

7. Try git pull. More errors.

8. Try git rebase. Everything is broken.

9. Cry.

10. Consider git reset — hard.

11. Realize you have no idea what you’re doing.

12. Call a senior engineer.

13. The senior engineer sighs deeply, then runs six obscure commands in the terminal.

14. Everything is fixed. You have learned nothing.

The Git Black Magic Society

At every company, there is one developer known as “The keeper of Git wisdom” who is capable of using Git at a professional level. You’ll see them casually rebasing like a hacker in a Hollywood movie, fearlessly force-pushing without breaking a sweat.

They do an interactive rebase without fear. They cherry-pick without breaking into a nervous sweat. They don’t fear a detached head. When they speak you nod along like you understand, but you’re hiding the truth. You type commands until something works and your shaky understanding of Git is based on memorization. You aren’t even on the path to be a master of Git, it it will likely never happen.

The Seven Stages of Git Grief

Denial

“I didn’t do anything wrong. It worked yesterday!”

Anger

“Why does Git hate me?!”

Bargaining

“Okay, maybe if I just force push, it’ll be fine…”

Depression

“My entire branch history is destroyed. I should change careers.”

Acceptance

“I guess I’ll just copy my code into a new branch and start over.”

So… Do You Really Know Git?

When a recruiter asks you if you know Git you do need to say yes. There isn’t a world where saying no will move you to the next stage of an interview process.

Yet most of us will never truly understand Git. We live in fear of breaking the repo, hoping that our daily interactions with git push don’t end in disaster. And yet, here we are — surviving, merging, and occasionally not breaking everything.

And if all else fails, you can always do what every developer does in an emergency:

Clone the repo again and start over.

Conclusion

Git shouldn’t be a black box and really should be a tool we understand and use to achieve our particular goal. Perhaps if we trained junior developers to use the tools required for their job we wouldn’t be in this position, and things would be better for everyone? Unfortunately, we are in a timeline where recruiters instead ask developers whether they can use Git, and I think that’s the wrong question.

I guess the key question recruiters should ask at an interview is something different. When you use Git do you panic, or do you actually know what you are doing, or are you pretending?