Saving with Git before AI changes things

Why save before an AI assistant touches your files?

An AI assistant can change many lines in one reply, and some AI tools can edit files on your computer directly. Most of the time the change is close to what you asked for. Sometimes it also removes a line, renames something or rewrites a section, and the reply doesn't mention it. If you didn't save a copy first, you have to work out from memory what the file used to say.

Git solves this. A commit is a saved snapshot of your project that you can always compare against and return to. Commit before you ask, and every change the assistant makes becomes visible and reversible. The Git course on PlainFinch covers commits in detail; this lesson shows how they fit around working with AI.

What does the routine look like?

Four steps, every time you let an AI tool change code. They take less than a minute once they are a habit.

First, check that your work is saved and committed. git status lists any files you changed since the last commit. If it shows changes, commit them now with a message that says where you are. Second, ask the assistant for one small change, and apply it. Third, run git diff and read every line it shows. Fourth, either commit the change or throw it away.

git status
git add index.html
git commit -m "Nav and footer before adding join link"

# ask the AI tool, apply its change, then:
git diff

How does git diff show what the assistant did?

git diff compares your files with the last commit. Lines that start with + were added, usually shown in green. Lines that start with - were removed, usually in red. A changed line shows up as one removed line followed by one added line.

This makes silent changes loud. In the practice area, the assistant says it only added a link. A diff of its answer would show one green line in the navigation, and one red line in the footer: the meetings line, gone. You don't have to spot a missing line by reading the whole page. Git points at it.

Read the red lines first. Additions are usually what you asked for. Removals are where the surprises hide, because nobody asked for them and the reply rarely mentions them.

       <a href="#contact">Contact</a>
+      <a href="#join">Join the club</a>
     </nav>
...
   <footer>
-    <p>Meetings every second Tuesday at the library, 19:00.</p>
     <p>Questions? Ask at the front desk.</p>

How do you put back a line the AI removed?

For one line, copy it from the diff (without the -) and paste it back where it was. That is what you practise here: the reply's code is in the Code tab, the meetings line is missing from the footer, and you add it back by hand. The **Review** view highlights your restored line against the assistant's version.

If the whole change is wrong, throw it all away. git restore index.html puts the file back exactly as it was at the last commit. Use it with care: it also discards any of your own changes since that commit, which is one more reason to commit before you ask. Older guides use git checkout -- index.html for the same job; both still work.

git restore index.html

What should the request look like?

Small. The smaller the request, the smaller the diff, and the easier it is to spot a line that shouldn't have changed. Name the one change, paste the part of the page it affects, and say that nothing else should change. The **Prompt check** view ticks goal, context, a small step and limits.

A limit like “don't change anything else” helps, and you still check. In the practice area the assistant follows most of the request and still drops a footer line. Real tools do this too, often when they rewrite a whole file to change one part of it.

Please add one small change to my bird club page: a "Join the club" link at the end of the main navigation, pointing to #join. Here is my nav:
<nav aria-label="Main">
  <a href="#events">Events</a>
  <a href="#sightings">Sightings</a>
  <a href="#contact">Contact</a>
</nav>
Don't change anything else on the page.

What happens without a commit?

Send a request without a size limit and the assistant redesigns your header: a new top bar, new fonts, a gold button, two navigation links gone, and the lang attribute removed from the page. If you had applied that to your real file without a commit, getting back to your old header would mean retyping it from memory or hunting through backups.

With a commit, it is one command. That changes how you can work: you can try an ambitious suggestion, look at it, and throw it away with no cost. Commits make it safe to experiment.

Without Git, the minimum safety net is a copy. Duplicate the file as index-before-ai.html before you paste in any AI change, and compare the two afterwards. It works, and it is clumsy: copies pile up, you forget which is which, and comparing them by eye misses single lines. Git does the same job properly.

When should you commit the AI's change?

After you have read the diff, tested the page and fixed anything wrong. Then commit with a message that says what changed, such as “Add join link to nav”. Some people mention in the message that an AI tool helped. Whether you do is up to you and your team; either way, you should have reviewed every line before it went in.

Commit each small change separately. If a later change breaks something, you can go back one step instead of losing an afternoon of work. A history of small, checked commits also makes it easy to find which change introduced a bug.

How is this different from the pretend assistant here?

The practice area doesn't run Git, so you restore the missing line by hand. The Review view plays a part of the diff's role, highlighting what you changed after using the reply. On your own computer, git diff shows the assistant's changes against your last commit, which is the comparison that catches silent removals.

Real AI tools that edit files directly can change several files at once. The routine stays the same and is even more important: commit first, ask for one thing, read the full diff across every file, then keep or discard.

Field notes

• Commit before letting an assistant change code, so you have a safe point to go back to.
• git diff shows added lines with + and removed lines with -.
• Keep requests small so the diff stays small and silent changes stand out.
• Commit the assistant's change only after you have read the diff and tested the page.

Easy to get wrong

Without a commit there is nothing to compare against, and git restore would also throw away your own unsaved changes.

The assistant's summary describes what it meant to do. The diff shows what it actually did.

When changes are mixed together, one bad change is hard to find and hard to undo without losing the good ones.

Questions people ask

Do I need Git to use an AI assistant safely?

It isn't required, but it is the easiest safety net. Without it, at least keep a copy of the file before you paste in any AI changes, and compare the two.

Does git diff show changes I haven't saved in my editor?

No. Git only sees what is saved to disk. Save the file first, then run git diff.

What if I already committed the AI's change and then found a problem?

Fix it with a new commit, or use git revert with the commit's id to undo that commit with a new one. The Git course covers both.

Can I see the diff in my code editor instead?

Yes. Most editors show changed lines next to the line numbers and have a source control panel with the same diff. Use whichever you will check every time.