Why version control matters when an AI agent can change many files in a single session.
Agentic coding tools can change many files in a single session. Without version control, you lose track of what changed and when, and you have no way to compare the result to the version you trusted before. Git keeps that record. It saves the history of changes, lets you label them with messages, and gives you a known state to return to if the work goes wrong.
A readable record of change, and a known good state to return to if something breaks. With branches, you can run experiments without disturbing the version you trust.
The vocabulary is small. A repository (usually shortened to repo) is the project Git is tracking. A commit is a checkpoint in that history, saved with a message that explains what changed and why. A branch is a separate line of work for when you want to try something without disturbing the main version. A merge brings that separate line back into the main one. If the project also lives on GitHub or another remote host, push sends your local history there and pull brings shared history back to your machine.
The demos below show what a readable history looks like and how branches keep experimental work separate from the version you trust.
Select a commit to inspect what was saved at that point.
The first commit establishes a working baseline. Once that state is saved, you can inspect or revert any later change against it.
Create a branch, then merge it back, to see how Git separates experimental work from the main line.
An agentic coding tool will translate plain language into the right Git operations, so you only need to understand what each operation does. The examples below show the most useful ones.
For a project that has no repository yet:
Create a new git repository for this project
When you want to see what actually changed before committing:
Show me what files have changed since my last save
Once the work has reached a meaningful stopping point:
Save my changes with the message "added login page"
Useful before any experiment whose outcome is uncertain:
Create a new branch called feature-dark-mode
Once you are satisfied with the experimental branch:
Merge my feature-dark-mode branch into main
Sends your local history to the remote host:
Push my changes to GitHub
Reverses a recent change while keeping the history intact:
Undo my last commit, I made a mistake
Trace how the project reached its current state:
Show me the history of changes to this project
Commit at meaningful stopping points, and if the scope of a change feels fuzzy, ask to see what changed before you commit. It is a good idea to create a branch before any experiment that may go sideways. Commit messages should still make sense weeks later. Write something like "fixed layout bug in sidebar" rather than "updates." And if you are unsure what a Git operation will do, ask your tool to describe the likely effect first.
At some point you will hit a merge conflict: two lines of work changed the same part of the same file, and Git cannot decide which version to keep. Your coding tool can walk you through the resolution. Frequent commits with clear branch boundaries also reduce how often conflicts come up.
Git's full command set is enormous, and most of it is irrelevant here. You can do most of what you need with three habits: commit at stopping points, branch before experiments, and read the history when something looks wrong. You will pick up more operations as projects grow.