GitHub for People Who Have Never Written Code

The first time you ask an AI to improve an app you like, you will probably have an entirely reasonable thought: please don't fuck up the good bit.

Perhaps Visit Book finally lets you read a whole call note without opening another window. You want a better way to see tomorrow's appointments, but you don't want to lose that. The AI says the change is straightforward. Fine. You would still like a copy of what worked before it got enthusiastic.

Software developers have spent decades solving this problem. Git records versions of a project's files, along with descriptions of what changed. GitHub keeps a copy online, under your account, so those files and their history don't exist only on this computer. A project stored this way is called a repository, or repo: your Visit Book files together with their recorded history.

Codex can manage that history for you. The part worth understanding is what it saved and where you can find it. I don't want your confidence in the project to depend on the last AI message saying everything is fine.

Put your project on GitHub

Go to GitHub's signup page and create a personal account. Use an email address you control, complete the email verification, and save your account recovery details. A free account is enough for this project. The signup guide shows the current account steps. You don't need to establish an organization just because GitHub offers a button for it.

Return to Codex in your VisitBook folder. Ask it to set up Git for this project if it hasn't already, and to connect the project to a new private repository called visit-book in your GitHub account. Tell it to preserve the app's source files and the project instructions, while keeping passwords, private appointment records, and temporary build files out of the repository. Source files are the files used to make the application; Codex knows which ones belong in this collection.

Codex may install Git or GitHub's command-line tool and open a browser so you can sign in. Sign in on GitHub's page, rather than putting your password into the conversation. GitHub's guide to adding an existing project describes the process the agent can perform. You can ask it to explain an authorization screen in plain English before you accept it.

When it finishes, ask for the repository's web address and open it. It should look like github.com/your-username/visit-book, with your actual username, and show a Private label. You should see the project's files. Find START-HERE.md, the document you asked for in article two, and click it. Reading your own instructions on that page is more useful than staring at a hundred unfamiliar filenames and deciding GitHub must be for somebody else.

Bookmark the repository. Have Codex put its address in START-HERE too. You now have a way to find the project even if the computer containing your usual shortcut isn't available.

Save the good version, then change it

Ask Codex to record the current working version and send it to GitHub before making your next change. In Git's vocabulary, recording a version is a commit. Sending recorded commits to the GitHub copy is a push. The distinction matters because a commit on your laptop is still only on your laptop until it has been sent somewhere else.

Then ask for a change you can recognize. For this exercise, have Codex add a sentence to START-HERE: “Visit Book saves my call notes and appointments on this computer.” Ask it to commit and push that change, using a description that says what it did.

Open the repository in your browser and refresh the page. Click START-HERE and look for the new sentence. Then open the repository's commit history, linked near the file list, and select the change Codex just made. You should see its description and the text it added. The comparison between old and new files is called a diff. On this occasion, you know exactly what it ought to contain because you supplied the sentence.

This is the same machinery you will use for much larger changes. You may not be able to read the code for a new scheduling feature, but you can still find the change, read its explanation, and ask another AI to examine it. “Show me what changed when we added the appointment view” is a useful request. You don't have to settle for an agent's vague recollection of what it thinks it did yesterday.

If the sentence is on your computer but missing from GitHub, tell Codex that. It may have committed without pushing, pushed to a different repository, or worked on a different branch. A branch is a named line of changes within the project. The normal one is often called main; Codex can also use another branch to develop an experiment separately. Ask it to show you the right history and explain why you were looking somewhere else.

Here is the distinction to keep handy:

That last row explains a common annoyance. Codex changes the files, announces completion, and you open the app to find exactly the old behavior. Before asking it to rewrite the feature, ask whether it rebuilt and installed the updated application. You might simply be using yesterday's app. GitHub does not reach into your Start menu and replace a program because its source changed.

What GitHub will not save for you

Suppose you record ten calls in Visit Book after today's code was committed. Those call records live in the app's saved data. They were entered through the app, not written into its source files. Pushing the source to GitHub does not back them up. Likewise, recovering an earlier version of the program is different from recovering a note you accidentally deleted.

Ask Codex to state where Visit Book keeps those records and provide a way to back them up and restore them. We will use that recovery procedure later. The repository contains what another engineer would need to work on the program; the data backup contains the information you entered while using it. You want both.

There is also no rule requiring the AI that began this project to be the AI that finishes it. Another coding agent can read the repository, its instructions, and its history. That doesn't give the newcomer your entire experience of using the app, but it gives you a substantial starting point. You can say, “This is my project. Read how it works. Here's what I want to change.”

I consider that worth a GitHub account. The next time you choose an AI to work with, you can bring the actual project and its history with you.