Git and GitHub, explained for non-coders

For most of your career there was no reason to know what git was. It lived on the developer side of the building, and you never had to walk over. Building with an agent is what changes that. Your work is a set of files now, sitting in a folder, and files you care about need somewhere safe to live. You need two things for that: an undo button on your machine, and an online home your work can go to next.

The three names that sound the same

Git, GitHub, GitLab. They sound almost identical, which is most of the confusion. Here is each one.

So git is the thing itself. GitHub and GitLab are two places to keep it online, the way Dropbox and Google Drive are two places to keep the same files. You will not choose between them. You use GitHub unless someone hands you the other one.

The words you will hear

A few verbs travel with all of this, and one of them trips up everyone.

Push sends your saved work up to GitHub. Pull brings changes back down to your machine. Those two are the easy ones.

Pull request (or merge request)

A change offered up for review before it joins the main version. Despite the name it has nothing to do with pulling. GitHub calls it a pull request and GitLab calls it a merge request, but they mean the same thing. A “push request” is not real, just the two getting mixed up.

You will not touch a pull request working on your own. It starts to matter when a second person joins the project, a developer or a teammate. Then every change gets a look before it lands.

Your undo button

Start with the part you need on day one. Git saves a snapshot of your folder at a good moment and lets you return to it later.

You save when things are working. You let the agent make changes. If they are good, you save again. If they are not, you roll back to the last snapshot, and the mess is gone. A save point in a video game, for your files.

You will not memorize a single command. You ask the agent to set it up, then ask it to save or roll back in plain words whenever you want. This is the prompt to start with:

Set up version control for this project so I can undo changes safely.

1. If this folder is not a git repository yet, start one.
2. First, create or update a .gitignore so my .env file and any keys,
   passwords, or secrets are excluded. They must never be saved or uploaded.
3. Take a first snapshot (a commit) and label it "first checkpoint."
4. Then tell me, in plain English, how to ask you to save a checkpoint
   or roll back later.

Do not delete or overwrite anything without showing me first.

After that, a checkpoint is one sentence. Ask it to save where you are before you let it do anything big, and the road back is always there.

Keep your keys out

One thing is worth getting right the first time. When you save a snapshot you decide what goes into it, and your .env file with your keys must never be one of those things. The prompt above handles this by writing a .gitignore, the small file whose only job is to list what to leave out. You did the same thing when you connected your data.

This matters more the day you go online. A project on GitHub can be public, which means anyone can read every file in it. Keep yours private unless you have a clear reason not to, and keep the keys out of it either way. This is the one footgun in the whole course. A single file closes it, as long as .env is ignored before your first checkpoint; if a key ever does slip in, rotate it rather than just deleting it.

Where your work goes to live

The undo button earns its place on its own. GitHub is where this starts to change the job itself.

Think back to the page you built from a single prompt earlier in the course. GitHub gives it a home online and a first step toward going live. A host does the publishing. Connect the project once to a service like GitHub Pages, Cloudflare Pages, Netlify, or Vercel, free within their limits. Every checkpoint you push then triggers a deploy to the live site. You edit, you save, and the change is online, without anyone filing a ticket.

That is where it changes the work for a marketer. The copy and the meta descriptions on a site become things you fix yourself in minutes. Changing one line of wording across forty pages becomes a single instruction you hand the agent. When you want that, the second prompt sets it up:

I want to put this project on GitHub so it is backed up and I can publish it later.

1. First confirm my .env and secrets are in .gitignore and are not
   included. Do not upload anything until you have checked.
2. Help me create a repository and push this project up. Make it private
   unless I say otherwise, and tell me exactly what to click or approve.
3. When it is done, give me the repository link and explain how future
   checkpoints go up with one instruction.

The same door lets you hand a project to a developer when you need one. You can also start from someone else’s template instead of an empty folder.

What this asks of you

None of it asks much. One account, made once. The agent runs the commands and does the setup, including the .gitignore that keeps your keys out of it. The only moment you touch it directly is approving the login, which is a couple of clicks.

You do not need any of this to get value from an agent today. But the day you build something worth keeping, you will be glad its home was one prompt away.