GitHub for website owners who aren’t developers

What GitHub is, for a website owner

GitHub sounds more technical than it is. For a website owner, the important thing is simple: it gives you an account where the files behind your site can live, with a record of every change ever made to them, under your name rather than someone else’s.

Developers use GitHub for a great deal more than that, and most of what you’ll see on the site is built for them. You can ignore nearly all of it. The parts that matter to you fit in this guide, and none of them involve reading code.

What “source code” means for a website

A website is a folder of text files. The files describe every page, every heading, every button and every colour, in a form a computer can turn into the site you see in a browser. That folder is the source code. When an AI tool “builds your site”, the thing it actually produces is this folder.

You never need to open these files. But you do need to have them, for the same reason you keep the original files for your logo: they are the thing everything else is made from. Anyone who has the source code can rebuild, move or change the site. Anyone who doesn’t can only look at it.

What a repository is

A repository is what GitHub calls one stored folder of source code, together with its full history. Your website’s repository is the folder that makes up your website, kept on GitHub. People shorten it to “repo”.

A repository has an owner, which is the account it sits under. It has a name. It has a page on GitHub where you can see the files, and a list of every change ever made. That page is what you’re checking when you confirm your site is really there: you should see folders and files with names that roughly match your site, not an empty page.

Private or public?

A public repository can be seen by anyone on the internet. A private repository can be seen only by you and the people you specifically give access to. Both are free on GitHub, with no limit on how many private repositories you can have or how many people you can invite to them.

For a business website, private is the normal choice. The site itself is public, but the files behind it may contain things you’d rather not publish, and there’s no advantage to sharing them. Choose public only if you have a reason to.

What a commit is

A commit is one saved change to the repository, with a note saying what changed and who changed it. The history of a repository is just the list of its commits, newest first.

That is genuinely all you need to know. When your AI tool changes your site and the change appears on GitHub, that’s a commit. When a developer fixes something, that’s a commit. If anything ever goes wrong, the history is how someone finds the change that caused it and puts it back.

Why you, the owner, should have the repository

Because the repository is the site. If the repository is under your AI builder’s account, or a freelancer’s, then what you have is a view of your site, not the site itself. You can see it and, as long as they’re around, ask for changes. You can’t take it anywhere.

Builders shut down, change their pricing or drop features. Freelancers move on. Agencies get acquired. None of these has to be a crisis, but each becomes one if the only copy of your site is inside an account that stops being available. A repository under your own account means the worst case is inconvenience: you hand the files to someone else and carry on.

There’s a second, quieter reason. A site whose files live in a repository you own can be worked on by any developer and by any AI coding tool, not just the one that built it. That freedom is worth more the longer the site lasts.

Collaborators: giving others access without giving them ownership

A collaborator is someone you’ve invited to work on your repository. They can see the files and make changes, but the repository stays yours: you can remove them at any time, and only the owner can delete the repository, make it public, or move it to another account.

This is the right way to let a developer or an agency work on your site. Invite them as a collaborator on your repository, rather than letting them create the repository under their own account and sending you a link. When the work is done, remove them. Nothing else changes.

One detail worth knowing: on a repository owned by a personal account, every collaborator can make changes. There is no “view only” option. If you want finer control, such as someone who can look but not touch, that needs an organization account, below.

Personal account or organization?

GitHub has two kinds of account. A personal account is yours: you sign in to it, and it can own repositories. An organization is a shared account that a business owns. Nobody signs in to an organization directly; instead, people sign in to their own personal accounts and are made members of it. The organization owns the repositories, and its owners decide who can do what.

For a personal project or a very small business, a personal account is fine, and it’s where most people start. For a business with more than one person involved, or one that might change hands, an organization is better: the repository belongs to the company rather than to whoever happened to set it up, and members can come and go without the site moving with them. Organizations are free, too.

If the repository is already under someone’s personal account, GitHub can transfer it to an organization, or to a different personal account, without losing the history. Links to the old address keep working afterwards.

How AI coding tools work with a GitHub-backed site

Nearly every AI tool that builds websites can work with a repository on GitHub, and this is the main practical reason to have one. The pattern varies a little by tool:

• Builders with a GitHub connection such as Lovable, Bolt and v0 can create a repository under your GitHub account and keep it up to date as you work. Changes you make in the builder become commits in your repository. Some of them also pick up changes made elsewhere.
• Coding agents such as Claude Code, Cursor and Codex work directly on a copy of the repository. You ask for a change, the agent edits the files, and the change is committed to GitHub.
• Your host watches the repository. When a commit arrives, it builds and publishes the new version of the site.

The result is that the repository becomes the meeting point. The builder that made the site, a coding agent you try later, a developer you hire, and the host that publishes it all read from and write to the same place, and you own that place. Switching tools means pointing a new tool at the same repository, not rebuilding.

If your builder offers a GitHub connection, use it, and make sure the repository it creates is under your account or your organization. If it only offers a download, download the files and put them in a repository yourself. GitHub’s own instructions for creating a repository and uploading files are short and don’t require any software.

GitHub is not automatically the thing hosting your site

Connecting your site to GitHub stores the files. It does not, by itself, put a website online. That job belongs to a host, such as Vercel, Netlify or Cloudflare, or to the builder’s own hosting. The host reads the files from GitHub and serves the site to visitors.

GitHub does have a feature, GitHub Pages, that can serve simple static sites straight from a repository, but most AI-built sites need more than that. If you want to understand which service is doing which job for your site, read GitHub is not your web host.

A simple ownership test

If the files are in a repository under your own GitHub account, yes. You can download them as a ZIP from the repository page, hand the repository to a developer, or connect a different tool to it. If the only copy is inside the builder, the honest answer is no, and the fix is to connect or export it now, while the builder is still there.

A note on the ZIP download: it gives you the current files but not the history. That’s fine as a backup. For a full copy including every past change, a developer would “clone” the repository instead, which is a routine operation for them.

Checklist

On the two-factor point: GitHub requires it for anyone who contributes code, and if you lose your phone without recovery codes, GitHub may not be able to get you back in. Turn it on, save the codes, and treat the account with the same care as your registrar login.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• GitHub’s plans · GitHub
• About repositories: repository visibility · GitHub
• Permission levels for a personal account repository · GitHub
• Types of GitHub accounts · GitHub
• Transferring a repository · GitHub
• Downloading source code archives · GitHub
• About mandatory two-factor authentication · GitHub
• Recovering your account if you lose your 2FA credentials · GitHub
• What is GitHub Pages? · GitHub
• Deploying Git repositories with Vercel · Vercel