Git for Solo Builders | Safe Git Practices

Overview

If it is your project and you are the only one touching it, the goal is speed without losing the safety net. Commit often, keep commits small, and use shortcuts that remove the friction from doing it right every time.

Not sure which guide is right for you? See all three profiles.

The branch rule for solo work

In team contexts, branching exists to protect shared history and enable review. Solo, those reasons are less pressing. Some experienced builders commit directly to main on personal projects - that is a valid choice when you understand the trade-off and commit often enough to keep rollback precise.

If you are on a client project or anything you cannot easily reset, branch per feature. If it is yours to break, committing to main and moving fast is fine.

Shell aliases - the biggest win

The most effective change for any solo builder is removing the friction from committing. Add these to your ~/.zshrc or ~/.bashrc:

# Add all and commit in one command
alias gac='git add . && git commit -m'

# Add all, commit, and push in one command
alias gacp='git add . && git commit -m "$1" && git push'

Usage

gac "fix login redirect"
gac "add newsletter card to footer"
gacp "deploy: update pricing page"

Lower friction means more commits. More commits means a better safety net. After adding the aliases, reload your shell:

source ~/.zshrc

gac commits locally. When you are ready to push to remote, run git push separately. Use gacp when you want to commit and push in the same step - typically when you are done with a feature and want to sync.

Note: gac stages all changed files. This works on personal projects. On shared codebases, stage specific files by name to avoid including unrelated changes.

Multi-terminal workflow

The pattern used by most solo builders with Claude Code:

Agent terminal

Claude Code session running. This is where you give instructions and review the agent's output before accepting it.

Dev server terminal

Your local server running. You see changes live as the agent works, without switching context.

Git terminal

Dedicated to version control. You run git diff here, review the output, and commit when satisfied.

Using Claude's output as commit messages

Claude ends most sessions with a summary of what it changed - which files, what was added, what was fixed. That summary is often a better commit message than what you would write yourself. It is precise, it lists the files, and it explains the intent.

Copy it directly from the agent terminal into your git terminal. Shorten it if needed, but you rarely need to.

Letting Claude commit

Claude can run git add and git commit directly if you allow it. This saves a context switch but it uses tokens, and the agent may stage files you did not intend to include.

Recommended

Let Claude propose the commit message in its output summary. You paste it and run the command. Fast and still in control.

Acceptable

Let Claude run the commit directly on a personal project where you review the diff in the git terminal first.

Avoid

Letting Claude add, commit, and push in one step without reviewing. You lose the diff review moment.

Pre-session checkpoint

Before any agent session, save your current state:

gac "checkpoint: before agent session"

If the session produces bad output, you return here in one command:

git reset --hard HEAD~1

Recovery patterns

Undo last commit, keep changes

git reset --soft HEAD~1

Undo last commit, discard changes

git reset --hard HEAD~1

Restore one specific file

git checkout HEAD~1 -- path/to/file.ts

Stash without committing

git stash        # save
git stash pop    # restore
git stash drop   # discard