Git for AI builders: commits, branches and pull requests

Learn in your browser · Chapter 01 of 06

Git records a history of your project that you can read, compare and rewind. Install it and make your first commit.

Git is free version control software. It records a project folder as a series of snapshots called commits, each with a message, an author and a time, and the folder plus its history is a repository. Hosting services keep copies online and add team features, but Git runs on your computer and needs none of them.

Install Git using the current instructions on git-scm.com. Windows: install Git for Windows and use its Git Bash terminal, so every command here works exactly as on macOS and Linux (PowerShell can save files written with echo in another text encoding, changing what Git shows). macOS: typing git --version in Terminal offers to install Apple's Command Line Tools if Git is missing. Linux: use your package manager.

A line starting $ is what you type (without the $); the lines under it are the reply. Tested with Git 2.54.0 in Git Bash on Windows 11. Your IDs, dates and paths will differ. In your terminal, git log also shows labels such as (HEAD -> main), and git push and git fetch add progress lines.

$ git --version
git version 2.54.0.windows.1

Make a practice folder containing a repository. -b main names the first branch main; Git's documentation says its default is currently master.

mkdir git-practice
cd git-practice
mkdir prompt-library
cd prompt-library
git init -b main

Git replies Initialized empty Git repository in and the path. Now tell Git who you are; without --global, this applies to this repository only.

git config user.name "Example Learner"
git config user.email "learner@example.invalid"

Create two files. > writes a file, replacing what was there, and >> adds a line to the end.

echo "# Prompt library" > README.md
echo "Summarise this text in three bullet points." > prompts.txt

$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md
	prompts.txt

nothing added to commit but untracked files present (use "git add" to track)

Untracked means Git can see the files but is not recording them. git add chooses what goes into the next commit, and git commit records it.

$ git add README.md prompts.txt
$ git commit -m "Add README and first prompt"
[main (root-commit) 274c0c0] Add README and first prompt
 2 files changed, 2 insertions(+)
 create mode 100644 README.md
 create mode 100644 prompts.txt
$ git log --oneline
274c0c0 Add README and first prompt

git log lists commits newest first; 274c0c0 starts the commit's ID. Always give -m a message, or Git opens a text editor to ask for one (if it does, write a message, save and close it; in vi or Vim, the usual default, press Esc, type :q! and press Enter to cancel the commit). On Windows, Git may warn that LF will be replaced by CRLF: Git is adjusting invisible line endings, which is harmless here.

Learn in your browser · Chapter 02 of 06

A diff shows exactly what changed. Reading one before every commit keeps AI-written changes under your control.

Git holds work in three places: the working tree (files you edit), the staging area or index (what the next commit will contain) and the commits. These commands only look:

Scroll sideways to see every column.

Suppose a chat assistant adds the prompt you asked for but also edits your README unasked. Simulate it and read the diff:

echo "Suggest three test cases for this function." >> prompts.txt
echo "# Prompt library (generated)" > README.md

$ git diff
diff --git a/README.md b/README.md
index 7583c3b..845bdb4 100644
--- a/README.md
+++ b/README.md
@@ -1 +1 @@
-# Prompt library
+# Prompt library (generated)
diff --git a/prompts.txt b/prompts.txt
index 011add3..c40a787 100644
--- a/prompts.txt
+++ b/prompts.txt
@@ -1,2 +1,3 @@
 Summarise this text in three bullet points.
 Explain this error message in plain English.
+Suggest three test cases for this function.

Lines starting - were removed, + added, and a space means unchanged context; @@ gives line numbers. Stage only what you wanted, and git diff --staged then shows just prompts.txt:

git add prompts.txt
git diff --staged

Git's documentation suggests a summary of at most 50 characters, and Pro Git says to write it as a command ("Fix bug", not "Fixed bug"). A second -m adds a body.

$ git commit -m "Add test-case prompt" -m "Suggested by a chat assistant and checked by me. Left out its README edit."
[main 9083e5d] Add test-case prompt
 1 file changed, 1 insertion(+)

Then discard the README edit: git restore puts a file back to its last staged or committed version, throwing the edit away for good (chapter 4 has gentler options). Empty git status --short output means all is committed.

git restore README.md
git status --short

Learn in your browser · Chapter 03 of 06

A branch lets you try something without touching the main line. Merging brings it back, and sometimes Git asks you to decide.

A branch is a movable label on a commit. git switch -c name creates one and moves you onto it, so new commits move only that label. Merging brings another branch's commits into yours.

git switch -c add-review-prompt
echo "Review this code and list any bugs you find." >> prompts.txt
git add prompts.txt
git commit -m "Add code-review prompt"
git switch main

$ git merge add-review-prompt
Updating 7802b20..f729928
Fast-forward
 prompts.txt | 1 +
 1 file changed, 1 insertion(+)

Fast-forward: main had not moved, so Git just moved its label forward. When both branches change the same lines, Git reports a merge conflict. Make one:

git switch -c team-title
echo "# Prompt library for the team" > README.md
git add README.md
git commit -m "Retitle README for the team"
git switch main
echo "# Shared prompt library" > README.md
git add README.md
git commit -m "Retitle README as shared"

$ git merge team-title
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
$ cat README.md
<<<<<<< HEAD
# Shared prompt library
=======
# Prompt library for the team
>>>>>>> team-title

Nothing is broken. Above ======= is your side (HEAD, your current branch); below is the incoming branch. Edit the file into what you want and remove the markers (Git will commit them if you forget), then add and commit:

echo "# Shared prompt library for the team" > README.md
git add README.md

$ git commit -m "Merge team-title, combining both titles"
[main 1cd57f3] Merge team-title, combining both titles
$ git log --oneline --graph -5
*   1cd57f3 Merge team-title, combining both titles
|\  
| * 6a0e7d4 Retitle README for the team
* | 122d000 Retitle README as shared
|/  
* f729928 Add code-review prompt
* 7802b20 Start an ideas list

The graph shows the branches rejoining. To back out instead, git merge --abort tries to restore the pre-merge state; Git's documentation advises committing or stashing your own changes before merging, as an abort cannot always rebuild them.

Learn in your browser · Chapter 04 of 06

Git gives you several ways back. Use the gentlest one that works, and know which commands lose work for good.

An editor assistant asked to tidy one prompt may rewrite the whole file. Check a change's size first:

$ echo "You are a helpful assistant." > prompts.txt
$ git diff --stat
 prompts.txt | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

Five lines removed for one added is a warning sign. Unsure? Stash it: git stash saves uncommitted changes to tracked files and resets them to the last commit.

$ git stash push -m "Assistant rewrite of prompts"
Saved working directory and index state On main: Assistant rewrite of prompts
$ git stash list
stash@{0}: On main: Assistant rewrite of prompts

Your prompts are back; git stash drop would delete the saved attempt. Untracked files are not stashed by default. The ladder, gentlest first:

Scroll sideways to see every column.

git revert safely undoes a commit, even a shared one, by adding history rather than removing it. HEAD is your current commit; --no-edit skips the editor.

$ echo "Do whatever you think is best." >> prompts.txt
$ git add prompts.txt
$ git commit -m "Add open-ended prompt"
[main 3e90e5d] Add open-ended prompt
 1 file changed, 1 insertion(+)
$ git revert --no-edit HEAD
[main a045f45] Revert "Add open-ended prompt"
 Date: Sat Sep 26 09:24:54 2026 +0100
 1 file changed, 1 deletion(-)
$ git log --oneline -3
a045f45 Revert "Add open-ended prompt"
3e90e5d Add open-ended prompt
e2d9c68 Merge ideas-a, keeping both ideas

Learn in your browser · Chapter 05 of 06

A secret committed once stays in the history after you delete the file. Prevention is cheap; cleaning up is not.

An API key is a password that lets a program use a private or paid service. Assistants can write keys into code or settings files, which are easy to commit by accident. Try a fake one (never a real one):

echo "API_KEY=example-not-a-real-key" > .env
git add .env
git commit -m "Add settings"
git rm .env
git commit -m "Remove settings file"

The file has gone from the folder but not from the history. HEAD~1:.env means the file as it was one commit back:

$ git log --oneline -- .env
fcf18e3 Remove settings file
80dbc15 Add settings
$ git show HEAD~1:.env
API_KEY=example-not-a-real-key

Deleting only added a snapshot without the file; the earlier one still has it, and every clone and push carries the whole history. Treat a committed secret as leaked:

1. Revoke or rotate it first, with the service that issued it. OWASP and GitHub put this first; GitHub notes it may be enough.
2. Find out where the history has been pushed or cloned.
3. Only then consider rewriting history. It is a specialist job needing force pushes, and GitHub warns it cannot remove the data from other people's clones.

Prevention. A .gitignore file lists files that Git should not track:

echo ".env" > .gitignore
echo "API_KEY=example-new-key" > .env

$ git status --short
?? .gitignore
$ git check-ignore -v .env
.gitignore:1:.env	.env
$ git add .gitignore
$ git commit -m "Ignore local .env settings files"
[main cee7b13] Ignore local .env settings files
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

.env has left the status, and check-ignore -v names the rule hiding it. But .gitignore does not affect files already tracked (git rm --cached file stops tracking one but keeps your copy), or keys pasted into code, so also:

• Keep real secrets out of the repository; the UK's National Cyber Security Centre advises separating credentials from source code.
• Check git diff --staged for keys, tokens and passwords before committing.
• Never paste a real key into an AI assistant.
• Treat a hosting service's secret scanning as a safety net, not a plan.

Learn in your browser · Chapter 06 of 06

A remote is another copy of the repository that people push to and fetch from. Here a local folder plays the hosting service, so nothing leaves your computer.

Small teams often share one central repository. Each person pushes a branch and asks for review before it is merged into main: a pull request (some services say merge request). It shows the branch's diff; reviewers comment, request changes or approve, and automated checks can run.

A bare repository has history but no working files, as on a server. Create one, connect it as origin and push (upload) main; git init prints a path again.

cd ..
git init --bare -b main shared.git
cd prompt-library
git remote add origin ../shared.git

$ git push -u origin main
To ../shared.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Now be the collaborator: clone the shared copy and give it its own invented identity.

$ cd ..
$ git clone shared.git collaborator
Cloning into 'collaborator'...
done.
$ cd collaborator
$ git config user.name "Example Collaborator"
$ git config user.email "collaborator@example.invalid"
$ git log --oneline -- .env
fcf18e3 Remove settings file
80dbc15 Add settings

The fake key from chapter 5 came too. The collaborator pushes a branch (Git reports [new branch]):

git switch -c add-translate-prompt
echo "Translate this paragraph into plain English." >> prompts.txt
git add prompts.txt
git commit -m "Add translation prompt"
git push -u origin add-translate-prompt

Back in your copy, review it. git fetch downloads without changing your files, and the three-dot git diff shows what the branch changed since it split from main, as a pull request page does:

$ cd ../prompt-library
$ git fetch origin
From ../shared
 * [new branch]      add-translate-prompt -> origin/add-translate-prompt
$ git diff main...origin/add-translate-prompt
diff --git a/prompts.txt b/prompts.txt
index fc19b0e..330d0a1 100644
--- a/prompts.txt
+++ b/prompts.txt
@@ -3,3 +3,4 @@ Explain this error message in plain English.
 Suggest three test cases for this function.
 Rewrite this email to sound friendlier.
 Review this code and list any bugs you find.
+Translate this paragraph into plain English.

Describe changes so they can be checked:

• What changed, and why.
• How you checked it: commands run, results seen.
• What an assistant wrote and what you reviewed; follow any team policy on AI-assisted work.
• What is risky, unfinished or left out.

Review like a sceptic: read the diff, not just the description, and keep requests small. The UK's National Cyber Security Centre advises reviewing all code before merging, noting that attacks can be subtle or disguised.