A folder named Project_Final_v3_REAL.zip is a warning sign. Somewhere inside it may be the version that worked yesterday, but finding that version can take longer than fixing the bug. Add a teammate, two laptops, and a submission deadline, and manual backups become difficult to follow. You need a record of what changed and a way to compare versions before replacing anything.
Git provides that record. This guide takes you through a small student-project workflow: record a working milestone, inspect your changes, experiment on a branch, and combine work carefully. You can practise on a disposable folder before using it for an assessed assignment.
1. Understand snapshots instead of renamed folders
Git is a version control system that runs on your computer. A repository contains your project history as well as the files you are working on. GitHub and similar services can host copies of repositories, but they are separate services; you can learn local Git without publishing anything online.
Think of a commit as a named checkpoint of the tracked project. Git's official explanation of snapshots is useful here: a commit records a project state, while comparisons between states show changes. It is misleading to describe Git as only storing a list of changed lines. Text differences are how you often review the history.
Cloud drives may also keep version history, so Git is not the only way to recover an earlier file. Its particular strength is connecting related changes across a project: a program, its tests, and the explanation of how to run it can share one checkpoint. Word documents and images can be tracked too, although their changes are harder to review than plain text.
2. Follow the working folder, staging, and commit sequence
After installing Git from its official distribution or your school's approved software source, open a terminal in a small practice project. Configure the author name and email you want associated with commits; use an appropriate privacy setting before sharing a repository publicly. Then initialise the folder and check its status.
git init
git status
git add calculator.py
git diff --staged
git commit -m "Add temperature conversion function"
git log --onelineReplace calculator.py with a file that actually exists. The working folder contains your current edits. Staging selects the versions of files for the next checkpoint. Committing records that selection in the local repository. The Git guide to recording changes explains this sequence in more detail.
Run git diff before staging to inspect unstaged text changes. After staging, use git diff --staged to inspect what you are about to record. If you edit a file again after staging it, those later edits are not automatically included: stage the intended version again. This is why checking the diff matters more than typing commands quickly.
3. Make checkpoints that explain one useful change
A message such as “update” tells your future self very little. “Reject an empty temperature input” explains the purpose of the checkpoint. Keep each commit focused enough that a reader can describe its effect in one sentence. Completing input validation and changing the page colours are usually separate changes.
Before committing, run the checks your assignment needs. For a calculator, try a normal number, zero, a negative value, and invalid text. A commit is a record, not proof that the program works. If a checkpoint deliberately contains incomplete work, say so clearly rather than presenting it as a tested milestone.
Add a short README explaining the program, setup, and test inputs. For a longer assignment, the guide to documenting a school coding or science project can help you decide what evidence belongs beside the code. Useful history and useful documentation support each other.
4. Try an idea on a branch, then review the result
Suppose your calculator works and you want to add a graph. First commit the current working changes and check that the working folder is clean. Note the name of your starting branch; do not assume every repository calls it main.
git status
git branch --show-current
git switch -c bonus-graphMake the graph changes, test them, and commit them on the new branch. To combine the result, switch to the original branch and merge the experiment after reviewing it. The official branching and merging walkthrough shows how this works.
A branch does not protect uncommitted edits automatically. Save a deliberate checkpoint before switching tasks; if Git blocks a switch, read the message rather than forcing it. When teammates edit the same area, a merge conflict requires a decision about the intended final code. Read both versions, resolve the conflict together, and test the combined result.
A small project record you can copy
The following is an illustrative plan for a student calculator, not a record of a real student's work. Each checkpoint answers a different question. Adapt the filenames and checks to your assignment, and keep the corresponding test evidence in your project notes.
| Milestone | Commit message | Evidence to check |
|---|---|---|
| Basic conversion | Add Celsius to Fahrenheit calculation | Known inputs give expected outputs |
| Input handling | Reject blank and nonnumeric input | Invalid inputs produce a useful message |
| Graph experiment | Add labelled temperature graph | Axes, units, and plotted values agree |
| Submission preparation | Document setup and sample runs | A classmate can follow the README |
Before starting the next session, read the last message and write the next action. For group work, agree who reviews each change and where the shared repository lives. Follow your course's collaboration rules even when the software makes sharing easy.
Three mistakes to avoid
- Waiting until submission to commit: record meaningful milestones while the project develops. A final snapshot cannot reconstruct intermediate work you never recorded.
- Treating local history as a backup: a lost laptop can lose the repository too. Keep an appropriate second copy or approved remote. Never put credentials, private student data, or generated clutter into commits. A
.gitignorefile does not erase secrets already committed. - Using recovery commands without checking: inspect status and history first, and keep a copy of uncommitted work before attempting restoration. Ask for help when you do not understand what a command will overwrite.
0 Comments