Git & GitHub in the age of AI

This post is a brain dump of all the things I learned about using Git and GitHub without learning any of the syntax, and using AI agents instead.

What’s important to understand here is that this is not addressed to engineers. Git and GitHub are very powerful tools with very many commands, settings, and options that can be used by very technical people, but this is not that. This is describing the principles at play and how to use them via AI agents, so we’re not going to talk about the syntax of things. We’re not going to talk about all the specific details and limitations and particular ways to do things in some cases, because fundamentally, what happens when you use those tools via an agent is that the agent is able to understand feedback and error messages and adapt. You only need to understand the primary concepts behind the tool. By the end of this post, each concept we cover comes down to one plain-English sentence you can say to your agent.

What is Git?

Before we dive into practicalities, what is Git? Git is a version control system. The purpose is to allow you to keep all the variations, all the versions of text files — and code is just text files, but so are notes, drafts, and outlines, which is why this matters to non-engineers too. It allows you to have visibility on the difference between different versions. It allows you to make changes to your work with the safety of knowing that you can go back and fix mistakes, and that you can also try different versions of a change without losing everything.

An analogy that everybody probably is comfortable with is Google Docs versions, or WordPress revisions for a post. As you add content, edit content, modify a post, you have access to versions. You can go back and see how the post was looking before. Now, Git allows more than just version control, but this is the primary idea.

Git and GitHub

On the difference between Git and GitHub, that’s at the surface fairly simple. Git is a local tool that is running and available on your computer, and it allows you to track the versions and modifications of files on your computer. GitHub is the social version of it: a copy of your project hosted online, where multiple people together can track the different versions and the work each other is doing on the same text files.

That hosted copy is what unlocks everything beyond your own machine: your work is backed up elsewhere, it’s accessible from multiple machines if you have multiple machines, and it’s accessible to an agent in the cloud — if you use Codex or Claude Code from a mobile phone, for example, that agent reaches your project through GitHub.

It’s important to also remember that GitHub is the most popular solution for this, but not the only one. There are tools like GitLab or Bitbucket. GitHub is the one we use at Automattic; it’s the most popular, but it’s not the only one.

One thing you want to get right from day one: a repository on GitHub is either private or public. Private means only you (and people you invite) can see it. Public means the whole internet can. For personal notes, drafts, and half-finished projects, you want private, and it’s worth asking your agent explicitly: “Is this repository private?” It is the single setting on GitHub with the highest stakes, and it takes one sentence to check.

The tree

One thing I like in the way Git is often described is the analogy with a tree. The primary version of the project — the canonical one, the one that is actually live if it’s a website or a software product, or just the current state of your folder — is the trunk of the tree. Out of the trunk you can create branches. I like this image because, like every metaphor, it has limitations, but it’s a nice picture to have in mind.

On most projects, that primary branch is actually called main. In the WordPress world we call it trunk, which keeps the tree image alive. I’ll say trunk in the rest of this post; if you see main in a project, it’s the same thing.

Working locally with an agent

So how do you use Git day-to-day with an agent?

1. When you start working on a project and you decide that you want to track the evolution of its content (a project is generally a folder on your computer), you tell your agent: “Hey, I want to track this with Git.” There’s nothing else you need to do. The agent knows exactly the syntax to set up the Git repository. The repository is fundamentally this folder along with all the files specific to Git that track the changes you make over time.
2. Something important to note: when you put a new file in a folder that is a Git repository, that file is not automatically tracked. You have to tell your agent, “Hey, I want to track the new file,” or “track every file.” You can also give the agent a standing rule — “every time I add a file here, track it” — or ask it to wait for your call each time.
3. Very important to know: there is a special file in a Git repository called .gitignore. It lists files and folders that you want to be certain will remain local to your computer. Whatever is listed there will not be sent away when you synchronize your repository with GitHub.
4. Be careful with any file that contains private data or credentials. It’s good discipline to tell your agent, “Hey, list every file that you think should be ignored” — but don’t just trust the agent. It can do most of the work for you, but it’s important that you double-check what it has done.

One more thing about .gitignore, and it’s the kind of detail that actually matters: ignoring a file only protects it if it was never tracked in the first place. If a file with a password in it got committed even once, adding it to .gitignore afterwards changes nothing — the password is in the history, and it will go to GitHub with the next push. If that ever happens, tell your agent: it can scrub the file out of the history. And treat the credential as burned anyway — rotate it.

Committing

Once you have a repository and files you’re tracking, and you start working on them alone or with your agent, you have to remember to commit your files regularly.

Committing means saying: “I want to take a snapshot of this. I just changed a number of files; I want to record my changes and write a short note of explanation.” That note is called the commit message. It’s very useful, because when you’re trying to identify a change you made in the past, it’s very practical to go through the list of commit messages — and if it’s not you looking, your agent is going to need them.

One of the benefits of AI agents is that you can tell them to handle the commit messages, so you don’t need to write them yourself — particularly when the changes are the result of work you did together, because the agent has all the context. In general, when I need to commit something, I just say “commit the changes until now” or “commit everything,” and Claude in my case, or Codex, handles the commit message without a problem. It’s generally totally okay to have commit messages written by the AI: they’re not engaging writing, they’re literally just there to describe what was done so information can be located later.

How often is “regularly”? My rule of thumb: commit at the end of a working session, or the moment losing the work you just did would annoy you. You can also give your agent a standing rule to commit as it goes.

Going back

As you work and commit regularly, here is what it buys you: if at some point you realize that you liked a version of your files better before — you modified something in a way you don’t like, you deleted something you didn’t want to delete, you reorganized the structure of a file and regret it — you can ask the agent to go back. “Hey, show me the commits from today,” or from yesterday, or the full list. Then: “Go back to that one.” Every commit has its message, and it is also identified by a unique ID, a string of characters that lets the agent identify it exactly.

And maybe the request I use most day-to-day is simply: “Where are we?” Which branch am I on, what has changed since the last commit, is there anything not yet pushed? The agent answers in plain English. It’s the Git equivalent of glancing at your desk before starting to work.

Connecting your computer to GitHub

At this point, this is the basics of working with Git locally, on your own, in a folder. Version control: you can go to the past and come back to the present. To get the rest — backup, multiple machines, collaboration, cloud agents — you connect your local repository to GitHub. There are two directions, depending on which side existed first:

1. If the GitHub repository existed first, you tell your agent to clone it. You go to GitHub, grab the URL of the repository, give it to your agent, and say “clone it in this location.” It brings all the files and all the history of that repository onto your machine.
2. If the project started on your machine, you tell your agent: “Create a remote on GitHub and push this repository there.” The agent creates the GitHub side and sends everything up.

On terminology, here is the mental model that finally made this click for me: your local repository keeps a small address book of other copies of the project. Each entry in that address book is called a remote, and the default entry — the one created automatically whether you cloned from GitHub or pushed to it — is named origin. That’s all origin is: the default name in the address book. It works the same in both directions.

One practical note, outside the scope of this post: your agent needs access to your github.com account (or your company’s GitHub) to do any of this on your behalf. How to grant that access is a separate post. Assuming the agent has access, or the repository is public, the two directions above are all you need.

Push, pull, and staying in sync

Let’s talk terminology. When you say push, it means sending changes from your computer to GitHub. When you say pull, it means bringing changes from GitHub to your computer.

One thing worth making explicit: commits are local until you push. Committing takes the snapshot; pushing is what sends it away. If you want your work backed up on GitHub, the sentence is “commit and push.”

If you work from several machines, one habit prevents most trouble: start each session by asking the agent to pull. That way you’re always working on top of the latest version of your own work.

As long as you’re working alone, you can generally push and pull quite easily. But there are situations with conflicting changes: say you modified some files on your laptop, and modified the same files differently on your desktop Mac. The first machine pushes fine; the second one finds that the files on GitHub have changed in a way that doesn’t match its local history. That creates conflicts — and this is an area where LLMs are amazing, because resolving conflicts used to be tedious manual work. You’d go through the file line by line, understand the differences, and decide what to keep.

Git itself merges changes automatically as long as they don’t touch the same lines. When they do — say you rewrote the same sentence in two different ways — someone has to decide, because you can’t keep both. Agents resolve most of these situations on their own and highlight the ones where the human decision is the point: “You changed this sentence two different ways; which one do you want?”

Again: you don’t need to know the details. You tell your agent, “Push my changes to GitHub,” and the agent will tell you if there is a conflict it cannot resolve on its own, and ask you how to settle it.

Branches: parallel timelines

So far, even with GitHub in the picture, we’ve described working alone on one line of history. What happens if multiple people work on the same thing — or even if you’re alone and want to work on different aspects of your project at different moments? You don’t want all those changes tangled in the same history, because then, if fixing one mistake means rolling back four commits, you roll back everything those four commits were carrying — including later changes you wanted to keep.

To solve this, we have branches — and this is where the tree image shines. When you create a branch, what you’re saying is: I’m going to make changes here, but I want them isolated from any other changes — someone else’s, or my own on another front.

Let’s take a very simple example. I’m looking at a draft of a post I’m writing. At some point I decide I need a pass to fix all the typos and grammar. I also have in mind a pass to shorten the text as much as I can. If I do them sequentially on one timeline and, halfway through the shortening pass, I realize I made a mistake back in the typo pass and want to roll back — now all the shortening work after that point is in jeopardy. Instead, I create one branch to fix typos and another branch to shorten the text. Each branch carries its own history, its own timeline of changes, and going back and forth in one doesn’t affect the other.

You don’t even need to name branches — tell the agent what the branch is for, and it picks a sensible name. If you need switching between branches just ask your agent.

Pull requests

At some point I might decide that the changes in my branch are satisfactory and I want to bring them into the primary version of the project, into trunk. That is the notion of creating a pull request, and then merging it. The name comes from the perspective of an external contributor to a project: “Here are the changes I’m contributing” — and the project maintainer can pull those into the primary branch. If you’re working alone, you’re on both sides of this conversation; if you collaborate, you might genuinely be on one side of it. The notion is valuable in both cases.

What’s beautiful about a pull request is that someone else can test your branch before anything is merged. They tell their computer to fetch that branch from GitHub and try your changes locally. People create branches to make changes, other people pull those branches and test them, and only once the changes have been validated do they get merged into trunk.

If you go look at a pull request on github.com, here is what you’ll see: every changed line, in red (removed) and green (added); a conversation thread where people comment on the changes, sometimes line by line; and a merge button for when the changes are accepted. That one page is where most of the collaboration actually happens.

When trunk moved while you worked

Now, an important situation to understand. Let’s imagine it’s 10:00 in the morning and I want to make some changes to my project. I create a branch and work for a few hours. While I’m at it, a colleague creates their own branch — and merges it into trunk at noon. At 2:00 p.m. I’m done and ready for my pull request. But trunk is no longer the trunk I started from: it moved at noon.

Can I still create my pull request? Most of the time, yes. GitHub compares my branch against trunk as it is now, and as long as our changes don’t collide, merging works fine — the histories get tied together quietly. Where it gets interesting is when we touched the same files: then I need to ask my agent to rebase the branch.

Rebasing means the agent takes the commits from my branch and replays them on top of the latest trunk — as if I had started my work at noon instead of 10:00. My branch gets grafted higher up the trunk; trunk itself is never touched. If my colleague worked on different files, this is trivial and automatic. If we modified the same lines, we’re back in the conflict situation from earlier — and again, the agent resolves most of it and asks me only about the genuine decisions.

What’s important to remember is that, although I just explained all these concepts, in practice you say: “I’m ready to create a pull request.” The agent checks whether trunk has changed since you branched, suggests a rebase if needed, and solves conflicts for you most of the time. You don’t have to remember the steps.

After the merge: cleanup

There is some cleanup after a pull request is merged. Your branch has served its purpose — it has been merged, and you’re not going to keep it. You delete it on GitHub, and nothing is lost: the merged pull request page keeps the whole diff and conversation forever.

Then your own machine needs to catch up. Most of the time, all I tell my agent is: “I merged pull request number seven.” And it says: “Great — switching back to trunk, pulling the changes, and tidying up the old branch locally.” The deletion on GitHub doesn’t propagate to your machine by itself; the agent does that housekeeping.

The toolbox

So, in a nutshell, what do we have at our disposal?

• We can ask the agent to create a Git repository in a folder.
• We can ask it to track certain files, or everything.
• We can tell it to ignore some files — and verify the list ourselves, because ignored files must never reach GitHub.
• We can ask, at any moment: “Where are we?”
• We can commit our changes, and let the agent write the commit messages.
• We can create branches, switch between them, and work in parallel timelines.
• We can push to GitHub and pull from it.
• We can create pull requests, rebase when trunk has moved, and merge.
• We can delete merged branches and let the agent tidy up.

All those things are the concepts we manipulate. The agent knows the syntax for all the details.

Two things I’m deliberately leaving out, so you know the map is complete: forking, which is how you contribute to a project you don’t have write access to (your agent knows what to do the day you need it), and GitHub’s own web editor, which is handy for one-character fixes directly in the browser.

The words, in one place

• Repository — a folder whose history Git tracks.
• Commit — a snapshot of your changes, with a note.
• Commit message / ID — the note, and the unique identifier of a snapshot.
• Branch — an isolated timeline of changes.
• Trunk (or main) — the primary branch; the canonical version.
• Push / pull — send changes up to GitHub / bring them down.
• Remote / origin — an address-book entry pointing to another copy of the repository / the default entry’s name.
• Clone — copy a GitHub repository, history included, onto your machine.
• Pull request — proposing a branch’s changes for trunk.
• Merge — accepting them.
• Rebase — replaying your branch on top of the latest trunk.
• Conflict — two changes to the same lines; a human decision, mostly pre-chewed by the agent.
• .gitignore — the list of files that stay local, provided they were never tracked.

The point

If you remember one thing from this post, make it this: every concept above is one plain sentence to your agent. “Track this folder.” “Commit everything.” “Where are we?” “I’m ready to create a pull request.” “I merged number seven.” The syntax was never the point — the concepts are yours, the details are the agent’s.

The one thing this post assumed away is access: your agent needs to be connected to your GitHub account to do any of this for you. That’s the subject of a separate post.