Agent Foundations for Marketers · Lesson 7 of 8

Git and GitHub, explained for non-coders

Git, GitHub, and GitLab sound the same and are not. What each is, and why building with an agent is the moment a marketer finally needs them.

For most of your career there was no reason to know what git was. Building with an agent 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.

Git: Saves versions of your files on your computer so you can undo. On its own, before you push or pull, it never touches the internet.

GitHub: The most popular place to keep git projects online. The one you will meet first.

GitLab: The same idea from a different company, more common in bigger businesses. Works just like GitHub.

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 use GitHub unless someone hands you the other one.

The words you will hear

A few verbs travel with all of this. Push sends your saved work up to GitHub, and pull brings it back down. The one that trips everyone up:

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.

Your undo button

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.

Assignment: turn on the undo button

Paste this in the folder you have had open all course, the project holding your page and the tempo folder. Version control goes on your project, not on Tempo; the practice company manages its own history. The ignore file this prompt writes keeps your secrets out and leaves Tempo alone from the very first checkpoint.

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.
   Add the tempo folder to .gitignore too; it is practice material that
   manages its own history and my checkpoints should leave it alone.
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.

Done when the agent confirms a first checkpoint and has told you, in plain English, how to save and roll back.

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

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.

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. This is the one footgun in the whole course, and one file closes it; 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. You edit, you save, and the change is online, without anyone filing a ticket.

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.

Assignment: put the project on GitHub

Run this when you have something you would mind losing. The checkpoints so far live on the laptop itself, and a dead or stolen machine takes them with it; GitHub keeps a copy somewhere else. The agent checks your secrets are excluded first, then walks you through the one sign-in GitHub asks for.

I want to put this project on GitHub so a copy lives off this machine 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.

Done when the agent hands you a repository link and your project shows in your GitHub account.

The same door lets you hand a project to a developer when you need one. You can also start from someone else’s work instead of an empty folder, and you have already done a version of that. The practice company from the context lesson came from GitHub, and what you grabbed then was a snapshot. Cloning is the living version, still connected to its source, and it makes a good first real git move.

Assignment: clone the practice company

You are swapping the Tempo snapshot for a live clone, a repository nested inside your own. The prompt keeps the two from tangling: your checkpoints leave Tempo to manage itself.

Clone the practice company from github.com/nicolaas-spijker/pmm-agent-demo. If this project already has a tempo folder from the context lesson, replace it with the clone so it stays connected to its source. Confirm tempo is still listed in this project’s .gitignore so my own checkpoints leave it alone, and delete any workshop folder the clone brings back. Then show me its checkpoint history.

Done when the agent shows you Tempo’s checkpoint history.

Every line in that history is a checkpoint someone saved, with a note saying what changed, which is exactly what your own project’s history looks like from the outside. And because the clone stays connected, one instruction pulls down whatever changes upstream later. A snapshot goes stale. A clone can catch up.

What this asks of you

None of it asks much: one account, made once, and a login approval that 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.