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.

Writing and debugging Python samples as part of my AI evaluation work changed how I think about this. When you review code all day, you learn that the bugs that hurt most are not the dramatic crashes. They are the small wrong answers nobody notices. A few tests catch those early, and they do not take long to write.

Start by pulling logic into functions

You cannot easily test a script that does everything at the top level. The first step is moving the real work into small functions that take input and return output. Reading files, printing and calling APIs stay at the edges. The decisions live in the middle, where a test can reach them.

Here is a small example. Say a script reads order amounts as text and needs to turn them into numbers, skipping anything invalid. This lives in a file called amounts.py.

def parse_amount(text):
    cleaned = text.strip().replace("$", "").replace(",", "")
    if cleaned == "":
        return None
    try:
        value = float(cleaned)
    except ValueError:
        return None
    if value < 0:
        return None
    return round(value, 2)


def sum_file(path):
    total = 0.0
    for line in path.read_text().splitlines():
        value = parse_amount(line)
        if value is not None:
            total += value
    return round(total, 2)

Write the first tests

Install pytest with pip install pytest, then create a file whose name starts with test_, such as test_amounts.py. Every function in it whose name starts with test_ is a test.

from amounts import parse_amount

def test_plain_number():
    assert parse_amount("42") == 42.0

def test_dollar_sign_and_commas():
    assert parse_amount("$1,250.50") == 1250.5

def test_blank_is_none():
    assert parse_amount("   ") is None

def test_text_is_none():
    assert parse_amount("ten dollars") is None

Run pytest in that folder and it finds the file, runs every test, and tells you which ones failed and why. Plain assert statements are enough. When one fails, pytest shows the actual value next to the expected one, which is usually all you need to find the problem.

Test the edges, not just the happy path

The test that proves "42" becomes 42.0 is the least valuable one. The useful tests sit at the edges: blank strings, extra spaces, symbols, values that are far too large, and input in a format you did not expect. When I review code, the edge cases are where most bugs hide, and the same is true for my own scripts.

A good habit is to ask one question before writing tests: what is the strangest input this function will realistically see? Then write a test for exactly that.

Use parametrize to keep tests short

When you have many similar cases, pytest lets you list them in one place.

import pytest
from amounts import parse_amount

@pytest.mark.parametrize("text, expected", [
    ("42", 42.0),
    ("$1,250.50", 1250.5),
    (" 7.1 ", 7.1),
    ("", None),
    ("abc", None),
])
def test_parse_amount(text, expected):
    assert parse_amount(text) == expected

Each row runs as its own test. Adding a new case becomes a one line change, which means you will actually do it.

Turn every bug into a test

This is the habit that pays off most. When something breaks, I write a test that reproduces the bug before I fix it. I run it, watch it fail, fix the code, and watch it pass. Now that bug cannot come back without the test catching it. Over time the test file becomes a record of every mistake the script has already survived.

Keep tests fast and independent

Tests that touch real files, networks or databases get slow and unreliable. For small scripts I avoid that by passing data into functions instead of having them load it themselves. When a function really does need a file, pytest provides a built in tmp_path fixture that gives each test its own empty folder, so tests never step on each other or on your real data.

from amounts import sum_file

def test_sum_file_skips_bad_lines(tmp_path):
    sample = tmp_path / "orders.txt"
    sample.write_text("10\n$20.50\nnot a number\n\n")
    assert sum_file(sample) == 30.5

That one test checks the file reading, the parsing and the skipping of bad lines together, without touching anything outside a temporary folder.

What this changed for me

More than fifteen years in logistics and manufacturing taught me that checks built into a process beat inspection at the end. Tests are the same idea applied to code. They are not about perfection. They are about being able to change a script on Monday without worrying about what you broke in the version from Friday. Start with three tests for the function you trust least, run them every time you make a change, and add one more each time something surprises you.

Originally published at tonycantave.com.