GitHub repository
A GitHub repository is the online home for a site's code, where every change is recorded, so you can see exactly who changed what and undo anything if needed.
A GitHub repository is where a site’s code actually lives while it is being built and after it ships. GitHub is a hosting service for code, and a repository is one project’s worth of it: every file, every past version, and a complete log of who changed what and when.
That log is the important part. Software built with version control does not just have one current state that gets overwritten each time something changes. It has a full history, so a change made last month can be inspected, compared, or reversed without guesswork. For a site running your business, that is the difference between “something broke and we’re not sure what changed” and “here is the exact change, and here is how to undo it.”
On the projects I run, the repository starts inside the Wired Builder organisation on GitHub while I am doing the active build work, and the client gets their own account on it from day one rather than waiting until the project wraps up.
Why it matters to you
Ownership of your own code is not a technicality. If the repository sits under a vendor’s personal account and that vendor disappears, or the relationship ends badly, you can be locked out of your own website with no clean way back in. A repository under your name, or one you have a standing account on, means that never happens.
The change history also matters the moment something goes wrong. Rather than trying to remember what was different about the site last week, I can look at the log directly and see exactly which change caused an issue, then reverse it precisely instead of guessing.
How I set it up
I keep the repository in the Wired Builder organisation while active work is happening, since that is where the day-to-day building and deployment pipeline lives, but the client gets their own account on it immediately, not at handoff. When the engagement is done, or whenever the client asks, the repository transfers fully into their own account. That is part of you own the code, and it is a standing offer, not something that has to be negotiated at the end.
What it looks like in practice
You will not spend your time inside GitHub. What you get instead is the peace of mind that the code exists somewhere concrete, under an account you control, with a complete record of its own history. If you ever bring in a different developer, they can open the same repository and see exactly how the site is built, with nothing hidden and nothing to reconstruct from scratch.
That is also what makes a full handover actually complete. A handover that does not include the repository is not a full handover, it is a copy of the finished product with none of the history or the ability to change it safely.
Questions I get about this
- What actually is a repository, in plain terms?
- It is a folder of your site's code, stored on GitHub's servers, with a complete history attached. Every change anyone makes gets recorded as its own entry, permanently, so nothing is ever silently lost.
- Do I need to know how to use GitHub myself?
- No. Day to day it is a developer's tool, not something a business owner opens. What matters to you is that you have an account with access to it, so the code is never locked inside someone else's login.
- What happens to the repository if we stop working together?
- You get full ownership. The repository can be transferred fully into your own GitHub account, and I can hand off the whole codebase so any other developer can pick it up.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.