AI + Git

7 min readGitHub Copilot & AI Engineering · AI + Git

Git produces a great deal of text that is precise, complete and hard to read: diffs, logs, blame output, conflict markers, reflog entries.

AI is unusually good at the specific job of turning that text into a summary a human can act on. It is correspondingly bad at knowing whether the summary matters, and completely unable to tell you what you intended.

This cluster is about the first half, with clear boundaries around the second.

Start with AI Commit Messages

Why this cluster comes first

Two reasons, and the second is the important one.

The risk is low. Nothing here grants an agent tools or credentials. The output is text you read before acting on. A wrong answer costs you a few seconds of scepticism rather than a production incident.

It teaches the habit everything else depends on. Every technique in this cluster works by giving the model the actual repository state — the real diff, the real log, the real error output — rather than a description of it.

That distinction is the difference between a commit message that summarises the change and one that invents a plausible reason for it. It scales up unchanged: an agent that writes code against the files it actually read is doing the same thing as a model summarising the diff you actually pasted.

What AI is good at here

Compression. Four hundred commits into a readable account of what changed. A thousand-line diff into the three things a reviewer needs to know first.

Explanation. What a piece of Git output means, in context, without you needing to know the terminology in advance. This is genuinely valuable for the parts of Git people avoid — reflog, detached HEAD, interactive rebase.

Drafting. Commit messages, PR descriptions, release notes, README sections. Text that has to exist, follows a convention, and is derived from something already in the repository.

Pattern-spotting in your own diff. A pre-commit read of what you are about to push, which catches the debug statement and the accidentally-committed file more reliably than your own eyes at the end of a long day.

What it is not good at

Knowing your intent. A diff shows what changed. It cannot show what you were trying to achieve, so a message describing why is either derived from what you told it or invented.

Judging significance. A one-line change to an authorisation check and a one-line change to a log message look similar in a diff. Which one matters is domain knowledge.

Semantic correctness. Whether a merge resolution preserves the behaviour both sides intended is a question about the running system, not about the text.

Anything requiring the state of your machine. Which branch you are on, what you have stashed, what you actually ran — unless you supply it.

The lessons

Lessons 1 to 3 are the daily-use cases, in increasing order of risk: describing a change, understanding history, and resolving a conflict. Lesson 4 covers reviewing your own work before anybody else sees it. Lessons 5 and 6 are the outward-facing artefacts — pull request descriptions and release notes — where the audience is somebody else. Lesson 7 covers documentation, which is where hallucination costs the most because nobody re-checks a README. Lesson 8 is troubleshooting, which is the highest-risk page in the cluster and the reason the safety framing exists.

The safety rule for Git commands

The one rule that matters, stated once here and repeated where it applies:

Before running an AI-suggested Git command that rewrites history, moves a branch, or deletes anything, you need to be able to say what it will do and what you would do if it were wrong.

That is not a rule about AI. It is the rule this curriculum has applied to git reset --hard, git push --force and git filter-repo since Pillar 1. AI makes it easier to obtain a command you do not understand, which makes the existing rule bind more often.

The practical version, for troubleshooting: supply the command you ran, its actual output, git status, your branch state, and what you were trying to achieve. A model given those five things gives useful answers. A model given “git is broken” guesses.

A worked example of the difference

The gap between a useful answer and a plausible one is usually a gap in what you supplied. Concretely:

Asking without the diff:

“Write a commit message for my changes to the auth module.”

produces something like “Refactor authentication module for improved maintainability” — grammatical, conventional, and derived entirely from the words “auth” and “changes”. It would fit almost any commit touching that directory, which is another way of saying it describes none of them.

Asking with the diff:

git diff --staged | <your AI tool of choice>

produces a message naming the function that changed, the parameter that was added, and the call sites that were updated — because those are facts in the input rather than inferences from a filename.

The same pattern holds everywhere in this cluster. git log --oneline -50 beats “summarise recent work”. The actual conflict hunk beats “I have a merge conflict”. The real error output beats “the push failed”.

None of this is a prompting technique. It is the observation that a model can only work from what it is given, applied to a tool that makes it easy to give it almost nothing.

Where these techniques run

The lessons here are deliberately tool-agnostic, because the technique outlives the interface. The same “give it the real diff” approach works from:

An IDE chat panel, with the diff attached as context — see Copilot Chat
The terminal, where Copilot CLI can run the Git commands itself
GitHub.com, for pull request and release-note work
Any other assistant, given the same input

Where a specific surface does something distinctive — the CLI running git diff for you rather than you piping it — the lesson says so. Otherwise, treat the technique as portable.

Prerequisites

You need working Git knowledge for this cluster, not despite the AI but because of it. Evaluating a suggested command requires knowing what it does.

Privacy and what gets sent

Worth deciding deliberately before adopting any of this.

Using AI on a diff means the diff goes to a model provider. For most repositories that is unremarkable. For some it is a policy question, and the things worth checking are: whether your organisation has content exclusion configured, whether the repository contains material that must not leave your infrastructure, and whether a credential could be sitting in the diff you are about to paste.

That last one is not hypothetical. A .env file in a diff is a .env file in a prompt. The secret prevention work from Pillar 5 is what stops it being there in the first place.

Common mistakes

Asking about the repository without showing it any of the repository. The most common cause of generic, confident, useless output.

Accepting a generated commit message that states intent. The diff cannot contain your reasons. A message asserting why is either something you told it or something it made up.

Trusting a history summary you have not spot-checked. Compression loses things. If a decision matters, verify it against the commits the summary claims to be based on.

Running a suggested destructive command to see what happens. The category of command most worth understanding first is exactly the category people are most tempted to delegate.

Letting AI write documentation nobody verifies. A wrong README outlives a wrong commit message by years, because nothing re-checks it.

Pasting a diff without looking at it. If it contains a credential, it is now in a prompt, and pasting it somewhere is not an operation you can undo.

After this cluster

AI + Git treats AI as a reader and a drafter. The next cluster treats it as an environment you configure — Copilot in an editor, shaped by instructions that persist across every interaction.

Next cluster — GitHub Copilot