Make your first local Git checkpoint
Practice inspecting, staging, and committing one small file before using version control on a real game.
First Play Studios · Edition 1 · Updated November 14, 2026
Two local commits whose differences you can inspect, with no remote upload.
Before you start- Git already installed
- A new empty practice folder outside your game project
- A plain-text editor and a terminal opened in that folder
In this guide
Practice with a deliberately small repository
Git records selected file states as commits. Start in a new practice folder so you can learn without involving a real project’s generated files or unfinished work. Create a plain-text README.txt containing one sentence about a tiny game idea, then run git init in that folder.
A repository is local unless you separately configure and use a remote. This exercise ends on your computer. Version control also does not replace an independent backup: a drive failure can affect both your working files and local repository.
Choose what enters a checkpoint
Run git status to see the file state. Stage only README.txt using git add README.txt. Staging selects the content for the next commit; an edit made after staging is not automatically included until you stage it again.
Review the staged content with git diff --cached. Commit identity is stored in commit metadata. If Git needs an identity, configure a name and email appropriate for this practice repository, using repository-local settings rather than changing every repository’s configuration. Never use a password or API key as identity information.
git init
git status
git add README.txt
git diff --cached
git commit -m "Record first game idea"Make the difference easy to explain
Add a second sentence describing the player’s main action. Run git diff before staging to see the working change. Stage the file again, review the staged change, then make a second commit with a message explaining the addition.
Use git log --oneline to see the two checkpoints and git status to confirm whether any changes remain. Before applying this to an actual engine project, learn that engine’s recommended ignore rules. Build outputs, imported caches, large binary assets, and credentials need an intentional storage policy; do not start by blindly staging the whole computer.
Two checkpoints you can explain
- Create README.txt in a new practice folder and write one game-idea sentence.
- Initialize the repository, inspect its status, stage just that file, and review the staged content.
- Create the first commit; if identity is missing, set user.name and user.email locally in this practice repository.
- Add one player-action sentence and make a second reviewed commit.
- Read the short log and explain what changed between the two checkpoints.
Check your result.
- The log contains two understandable commit messages.
- Only the intended practice file was committed.
- You can distinguish an unstaged edit from staged content.
Common mistakes to watch for.
- Running commands in the wrong folder.
- Assuming a later edit was included in an earlier staging operation.
- Treating a local repository as a separate physical backup.
Keep the conversation useful.
I am learning Git in a disposable practice folder. Here is my git status and the command I tried: [output]. Explain which content is unstaged, staged, or committed. Suggest one next command and its effect. Do not suggest destructive resets, deletions, or a remote push.
Sources & version notes.
Uses basic Git 2.x commands documented by the Git project. No hosting account or remote repository is needed.
Further reading from the original documentation:
Practice times are estimates. Software-specific exercises are documentation-based unless their version note says otherwise.A question or a small win?
Tell the workshop what happened when you tried this guide. Ask for a useful next step, or share something you got working.
See discussions about this guide We’ll include the guide link in your draft. Sign in to post, then add your own question or progress before sharing.