Git and version control
Protect your work with repositories, commits and a recovery path before AI makes larger changes.
A repository (repo) is a project folder tracked by Git so changes can be reviewed and restored. Git records versions of your files so you can compare changes or return to a known working state.
What this step is for.
Git records snapshots of project history. A repository is the project history; a commit is a named checkpoint; a branch can isolate work. AI assistance is much safer when every meaningful change can be compared and reverted.
Keep the scope small enough that you can inspect the result yourself. AI can accelerate the work, but it should not erase the distinction between a suggestion, a changed file, a successful build and a verified product.
Take one concrete action.
Initialize Git in your practice project, make a clean baseline commit, change one file, inspect the diff and commit the verified change. Then practice restoring the baseline in a disposable copy.
Create two checkpoints and safely inspect the first one
1. Install and identify Git. Install from git-scm.com/download/win. In PowerShell inside Documents\my-first-ai-project, run git --version, git init, git config --global user.name "Your Name" and git config --global user.email "you@example.com", replacing the example identity with your own.
2. First checkpoint. Run git add ., git commit -m "first working version", then git status. It should report a clean working tree.
3. Second checkpoint. Add Checkpoint two as the final line of README.md. Run git diff -- README.md, git add README.md, git commit -m "add second checkpoint" and git log --oneline -2.
4. Undo an uncommitted mistake. Add REMOVE ME to README without committing. Run git diff -- README.md then git restore README.md. The temporary line must disappear while Checkpoint two remains.
5. Inspect the earlier committed checkpoint safely. From git log --oneline -2, copy the short hash for first working version. Run git switch --detach HASH. Confirm README does not contain Checkpoint two. Do not edit files. Return with git switch - and confirm Checkpoint two is back.
Success: two commits remain, the working tree is clean and you can visit an earlier committed state and return without deleting history.
Turn the idea into evidence.
Repeat the detached-checkpoint visit using the first commit hash, then return immediately with git switch -. Do not make edits while detached.
Do not move on until this is true.
You can show two commits and explain how to return to the earlier one without guessing which files changed.
Why we use this principle.
Nyfir Studios treats generated output and verified output as different states. Development work on local AI, Android software and bookkeeping workflows has repeatedly shown that recoverable state, explicit tests and clear product status are more useful than simply producing more output.