Git and GitHub for people who are not developers

Why do you need this if an AI builds for you?

Because an AI that writes code changes a lot at once, and you only see what the screen does. Without version control, after a change you know that it works differently, but not what is different. And if it goes wrong after three changes, you do not know which of the three did it. With version control every change has a before and an after, and you can see them side by side: these lines were added, these are gone.

It is also the basis of ownership. A project that exists only in your build tool exists only as long as the tool and your subscription exist. A project in a repository that is yours can go with you to any other tool and any host. That is the first step over the cliff, and most build tools have a button for it.

And it is the way to learn without programming. If you look at the overview of what changed after every change, and ask the AI to explain it in plain language, after a month you understand more of your project than you thought you could. The article about vibe coding calls that the second track.

• Seeing what the AI changed, not just that it works differently.
• Being able to go back to a version that worked.
• Ownership: a project you can take with you anywhere.

What is a repository?

A folder with everything that belongs to your project, plus the complete history of that folder. GitHub describes it as a folder that contains related items, such as files, images and other folders, and that usually groups everything of one project. The difference from an ordinary folder is the history. A repository remembers every version of every file, and who changed what, when and why.

A repository lives in two places: locally, on your own computer, and remotely, at a service such as GitHub. You keep the two in sync by sending changes (push) and fetching them (pull). For anyone who works with a build tool, the tool usually does this: it writes to the repository on GitHub, and you can view it there or fetch it to your own computer.

Create the repository yourself, on your own GitHub account, and connect the tool to it. Then the repository is yours. The other way round, a repository the tool creates for you under its own account belongs to the tool. You only notice that difference when you want to leave.

• A folder with your whole project and its whole history.
• Local and remote, kept in sync with push and pull.
• Create it on your account, then connect; not the other way round.

What is a commit?

A saved moment. GitHub defines it as a saved change to files in a repository, with a message that explains what was changed and why. So a commit is not a file but a photo of the whole project at one moment, with a caption. The series of commits is the history of your project, and you can bring back any commit later.

The message is the most important part for a non-programmer. A commit with the message “sign-up form added, with a check on the email address” is still understandable in three months; a commit with “fix” is not. Let your AI write the message in plain language, and read it before you approve. If you do not understand the message, you do not understand the change, and that is the moment to ask.

Keep commits small. One change, one commit. Then the history is readable and you can go one step back without losing everything. Build tools often make a commit per instruction, and that is a good size.

• A photo of the whole project at one moment, with a caption.
• The message in plain language, and read it before you approve.
• Small: one change per commit.

What is a branch?

A separate version of your repository in which you can work without touching the main version. GitHub explains that the default branch is called main, and that you create extra branches to experiment without affecting the main code. On a branch you make commits as usual; only when you are satisfied do you bring them back to the main line.

For anyone who builds with an AI, a branch is the safe place for a big change. Let the AI build a new part on its own branch, look at the result, and then decide whether it may go to the main line. If it goes wrong, you throw the branch away and the main line is untouched. That is cheaper than reverting a change that was already in the main line.

The main line is what is live, or what can go live. Stick to this rule: main holds only what works. Everything you do not trust yet is on a branch.

• A separate version to work in without touching the main line.
• Big changes by the AI: on their own branch, look first, then decide.
• main holds only what works.

What are a pull request and a merge?

A pull request is a proposal to take the changes of one branch into another branch, usually into the main line. GitHub describes it as a proposal mechanism that shows the differences between the two branches. Others can review, comment on and improve it before the change is taken over. A merge is the taking over itself: the changes of one branch are combined into the other.

Even if you work alone, a pull request is useful, especially with an AI. It is the moment when you see all the changes of a branch together, line by line. You can ask the AI what a piece does before it enters the main line. Many build tools and agents can open a pull request themselves; you only have to read and press the button, or not.

After the merge the branch can go; the commits are now in the main line and the history is complete. That is the cycle: branch, commits, pull request, merge. The main line is one step further without ever having been broken along the way.

• Pull request: the proposal, with all differences visible.
• Merge: taking it over into the main line.
• Even alone: the moment to read before it can go live.

What is the difference between Git and GitHub?

Git is the program that keeps track of the history; it runs on your own computer and needs no internet. GitHub is a service run by a company that keeps repositories on the internet, with a website around it for pull requests, comments and collaboration. You can use Git without GitHub. You cannot use GitHub without Git, even though you never see Git there directly.

There are also other services that do the same as GitHub, under other names. The principle is the same: a remote place where your repository lives, on your account, with the option to give others access. Choose one, create an account with a password from your password manager and the second step turned on, and put your repository there.

What you put on GitHub is visible to whoever you give access, and with a public repository to everyone. So never put keys or passwords in a repository, not even in a private one; the security checklist has a check for it. Version control forgets nothing, and that is both its strength and its risk.

• Git: the program on your computer. GitHub: the service on the internet.
• Other services do the same; choose one and turn on the second step.
• Never keys in a repository; version control forgets nothing.

Which three habits are enough?

The first: after every instruction to the AI, read the overview of what changed. Not the code itself if you cannot read it, but the list of files and the message. Ask the AI to explain in three sentences what happened. If the explanation does not match what you asked for, something changed that you did not want.

The second: big things on a branch. A new part, a change to the database, a different way of logging in: first on a branch, look at it, then a pull request and only then the merge. Small things may go in directly, as long as the main line keeps working.

The third: fetch your repository to your own computer once a month and check that it is complete and starts. That is your backup of the code, and it is the test that you can manage without the tool. Whoever has these three habits has not become a developer. But they do have the control a developer has over what happens in their project.

• After every instruction: read the overview and ask for the explanation.
• Big things on a branch, with a pull request.
• Fetch it monthly and check that it starts.

Sources

Checked on 5 September 2026. The definitions of repository, branch, commit, pull request and merge come from GitHub's Hello World guide; the habits are a working method.

• GitHub Docs, Hello World

Further reading

Three places that connect to this.