Most of my code lives in small projects with exactly one contributor: me. A screen scheduling script, a folder of Python helpers, a data cleanup tool. For a while I treated Git on those projects as a backup button. I typed a commit once a day with a message like "updates" and moved on. Then I needed to find the exact change that broke something, and a month of "updates" told me nothing.
Git is not only for teams. On a solo project it is your memory, your undo button and your safety net. Here is the simple routine I use now, with the commands that matter and the habits that make them useful.
Start every project the same way
The first three minutes of a project decide how clean its history stays. I run this in a new folder:
git init
git status
Then, before the first commit, I create a .gitignore file. This keeps secrets, virtual environments and generated files out of the history, where they are painful to remove later.
.env
venv/
__pycache__/
*.log
output/
The .env line matters most. API keys and passwords belong in that file, never in code, and the ignore file makes sure Git never picks them up. If a secret does land in a commit, treat it as exposed and rotate it. Deleting the file afterward does not remove it from the history.
Commit small, and write messages for your future self
The habit that changed the most for me was committing one idea at a time. Not one day at a time. If I fix how a script reads dates and also rename a few variables, those are two commits.
git status
git diff
git add reader.py
git commit
I always run git status and git diff before committing. Status shows which files changed. Diff shows exactly what changed inside them. More than once that quick look has caught a debug print or a test value I forgot to remove.
Running git commit without a message flag opens your editor, which nudges you to write a real message. My rule is simple: the first line finishes the sentence "This commit will...". So instead of "updates" I write "Skip blank rows when reading order files" or "Retry API calls after a timeout". Six months later, those lines read like a changelog.
Use a branch for anything you might throw away
Branches feel like overkill when you work alone, but they are the cheapest experiment you can run. When I want to try a different approach, I make a branch first.
git branch retrylogic
git switch retrylogic
Now I can rewrite as much as I want. If the idea works, I switch back and merge it:
git switch main
git merge retrylogic
If it does not work, I switch back to main and delete the branch with git branch and the delete option. Either way, main stays in a state I trust. This is the same thinking I used for years in manufacturing: you do not test a new process on the line that ships product. You test it on the side, then move it over once it proves itself.
Know your undo commands
Most Git anxiety comes from not knowing how to back out. These three cover nearly everything I need on a solo project:
git restore reader.py
git stash
git stash pop
The first throws away uncommitted changes in a file and returns it to the last commit. Stash sets aside everything you are working on so you can switch tasks, and stash pop brings it back. For anything already committed, git revert creates a new commit that undoes an old one, which is safer than rewriting history.
Find the commit that broke things
This is where good commit messages pay off. When a script that worked last week fails today, I look at the history first:
git log
git show
Log lists commits with their messages. Show displays the full change for any commit you name by its ID. With small, clearly described commits, I can usually spot the guilty change by reading the list. For harder cases, git bisect walks through the history with you, checking out commits halfway between a good version and a bad one until it narrows down the exact commit that introduced the problem. On a project with a few hundred commits, that takes only a handful of steps.
Push somewhere off your machine
A repository that only exists on one laptop is one spilled coffee away from gone. I push every project to GitHub, private if it is not ready to share:
git remote add origin https://github.com/yourname/yourproject.git
git push origin main
After that first setup, pushing at the end of each work session is a single command, and the project is backed up with its full history.
The routine in one paragraph
Ignore secrets before the first commit. Check status and diff before every commit. Commit one idea at a time with a message that finishes "This commit will". Use a branch for experiments. Learn restore, stash and revert so undo never feels scary. Push at the end of every session. None of this is advanced Git. It is just enough structure that when something breaks, the history tells you what happened instead of leaving you to guess.
Originally published at tonycantave.com by Tony Sterlin Cantave, a Connecticut software developer.
Top comments (0)