What is Git, and why should your freelancer hand you the repository?

What it is, in plain words

Think of a shared document with “track changes” switched on, except it never forgets. Every time someone saves a meaningful step, Git records a snapshot of the whole project, the date, the person, and a one-line note saying what changed. That saved step is called a commit. The full pile of commits, plus the code itself, lives in a repository (often shortened to “repo”).

Three consequences matter to a buyer:

• Nothing is lost by accident. If a change breaks something, the version from yesterday is still there, and going back is routine.
• Every change has a name on it. You can see what was changed, when, and with what explanation, without reading code.
• The repository is portable. Whoever has it can carry on the work. Whoever does not have it is starting from zero.

Git itself runs on a computer. Services like GitHub or GitLab keep an online copy of the repository. When a developer pushes, they send their new commits to that online copy. Until they push, the work exists only on their machine.

A concrete example

I run a small backup job on the computer that holds my scripts and notes. Several times a day it commits whatever changed, with a message like “auto-backup” and the date and time, and pushes it to a repository online. Most days nobody looks at it. That is the point: if a file is broken or deleted, the earlier version is one lookup away.

It also taught me the difference between committed and pushed. In September, the login token the computer uses to reach the code-hosting site stopped being accepted. For about two days the backup job kept running and kept committing locally, but every push was refused. Four commits piled up on one machine while the online copy quietly fell behind. The same expired token stopped one of my publishing jobs too, and every scheduled run still reported success (the full incident). I now have a morning check that tests that login directly.

Many website hosts also deploy straight from the repository. One of my daily publishing jobs works this way: it commits the new page, pushes, and the host builds and publishes the site from that push. If the build fails, the job undoes its change and pushes nothing. The repository is not just a backup there; it is the thing the live site is made from.

Why it matters when you hire someone

When a freelancer builds or fixes an app, an automation script or a website, the code has to live somewhere. If it lives in their account, three problems follow:

1. You cannot leave. The next developer has nothing to start from except the live site, and rebuilding is far more expensive than carrying on.
2. You cannot see what you paid for. “Fixed the login bug” is a claim. A commit with that message, dated and attached to the changed files, is a record.
3. A bad change cannot be undone cleanly. AI-built apps in particular tend to break in a second place when one place is changed. With history, the developer can compare the version that worked with the one that does not. Without it, they guess. The guide on an AI-built app that breaks every time it is changed goes deeper on this.

This is why the acceptance lines for AI coding work start with “all code is in your repository, with commits you can read”. It is also the first thing to confirm in the handover checklist for a fixed AI-built app.

What to ask the freelancer

Before any paid work starts:

A good answer to question 1 is simply “yes”. If the developer prefers to keep the code in their own account until the final payment, agree a date when it moves to yours, and write it into the order. After each delivery, open the list of commits and check that the dates and messages match what you were told. You do not need to read the code to do that.