Git and version control

Git is how software teams change the same files at the same time without destroying each other’s work. It is assumed knowledge in every engineering role and explicitly taught in almost none, which is why it turns up so reliably as the thing that quietly goes wrong in a first job.

What the work consists of

Most days: branch, commit, push, open a pull request, respond to review. The skill is not the commands, which are few. It is keeping a history that another person can read later when something has broken and nobody remembers why a line is there.

What employers screen for

Legibility. Commits that do one thing, messages that explain why rather than restate what, and a branch a reviewer can follow without reconstructing your week from scratch. A public repository shows all of this before anyone reads a line of your actual code.

• Resolving a merge conflict calmly, without deleting the other person’s work to make it go away
• Reading history to find when a behaviour changed and what shipped alongside it
• Knowing what is recoverable — which is nearly everything, and knowing that is what stops the panic
• Never committing credentials, and knowing what to do in the hour after someone does

How to practise so it counts

Use branches and pull requests on your own projects even though nobody is reviewing them. The habit is what transfers, and arriving at a first job already fluent in the workflow removes the most common source of early embarrassment.

The honest limit

Two to three weeks gets you to competent and that is genuinely the end of it. It is a small skill with an unusually high cost of absence: nobody is hired for Git, and people are quietly held back by not having it.