A Git workflow for solo founders that does not waste time

Filed under Guide

By Gerald · 24 June 2026

Single developer working at a clean desk with a laptop

Enterprise Git workflows are built for teams. They have pull request templates, protected branches, code review rules, and release branches that exist to coordinate multiple people. As a solo founder, you are not coordinating anyone. You are trying to ship.

I spent my first year as a solo developer following Git Flow because it was what the tutorials recommended. Feature branches, develop branches, release branches, hotfix branches. I spent more time managing branches than writing code. It was absurd.

The workflow I use now is much simpler. It keeps my code safe, lets me experiment without fear, and adds almost no overhead to my day. This is how I manage Flow's codebase alone.

For a solo founder, Git should be invisible. If you are thinking about branches more than once a day, your process is too heavy.

The trunk-based flow for one person

The core idea is simple. You have one main branch. You create short-lived branches for specific changes. You merge them back quickly. That is the entire workflow.

The branches

main is always deployable. It is your source of truth.
feature/short-description is for any change that takes more than a few minutes.
fix/short-description is for bugs.

That is it. No develop. No release. No version branches.

The daily rhythm

Pull the latest main.
Create a branch: git checkout -b feature/add-search-filter.
Work.
Commit regularly with clear messages.
Push the branch.
Open a pull request against main.
Review your own changes.
Merge and deploy.

Pull requests are not for code review from others. They are for you. They force you to look at your diff before merging, which catches more mistakes than you expect.

Why not just commit to main directly?

You can, and some solo developers do. I used to. The problem is that once a bad commit is on main, it is harder to undo cleanly. A branch gives you a sandbox. If you realize the approach is wrong, you delete the branch and start over. No revert commits. No messy history.

Branches also let you work on multiple things in parallel. I might have a feature branch for a new UI component and a fix branch for a bug report, switching between them as I wait for test results or think through a design problem.

Commit hygiene for one person

Simple Git branch diagram with one main line — Solo developers do not need enterprise Git workflows.

Write commit messages you will understand in six months

A commit message should explain why the change exists, not just what changed. The diff shows what changed. The message should give context.

Bad: fix bug Good: Fix search filter resetting on page refresh

Bad: update styles Good: Increase contrast on disabled buttons for accessibility

Future you is the only reviewer. Write messages that future you will thank present you for.

Commit early and often

There is no cost to making a commit. If you have working code that passes tests, commit it. If you are trying an approach and it partially works, commit it. Small commits are easier to understand, easier to revert, and easier to cherry-pick if you need part of a change elsewhere.

I commit whenever I finish a logical chunk of work, which is usually every ten to thirty minutes. I push at least once per session, often more.

Use atomic commits when possible

An atomic commit is one that makes a single, complete change. It should leave the codebase in a working state. This is not always possible, but it is a good target. It makes git bisect useful if you ever need to find which commit introduced a bug.

The practical rules I follow

Never force push to main. If you need to rewrite history, do it on a branch before merging.
Keep branches short-lived. A branch that lives for days accumulates risk. Merge it or delete it.
Run tests before merging. Even a solo project benefits from a quick test pass. I use GitHub Actions to run tests on every pull request.
Tag releases. git tag v1.2.3 takes seconds and gives you a known good state to return to.
Write a changelog. Not for users, for yourself. When something breaks, the changelog tells you what recently changed.

What about staging and production branches?

If you have separate environments, you might be tempted to create staging and production branches. I avoid this.

Instead, I deploy main to staging automatically. When I am ready to release, I tag a version and deploy that tag to production. The tag is the snapshot, not a branch. This avoids the drift problem where staging and production branches diverge from main and each other.

If you need to hotfix production, create a branch from the production tag, fix it, tag the fix, and merge back to main. Do not maintain long-running environment branches.

Why I do not use Git Flow or GitHub Flow

Git Flow is designed for scheduled releases with multiple developers. It has five branch types and a release process that makes sense for enterprise teams. For one person, it is pure overhead.

GitHub Flow is simpler: branch, pull request, merge. It is close to what I describe, but the emphasis on continuous deployment and team review assumes a team context. As a solo founder, I adapt it by using pull requests for self-review rather than for team coordination.

The workflow here is essentially trunk-based development with a single permanent branch. It is the lightest system that still protects your code.

When this workflow is not enough

This approach assumes you are the only person committing code. If you bring on a co-founder or hire a contractor, you need more structure. Add branch protection rules, require pull request reviews, and agree on commit message conventions. The transition is not hard because the foundation is already simple.

If you are managing a product with multiple release streams, long-term support versions, or complex deployment pipelines, you will need more branching. Most SaaS products built by small teams do not need that complexity for a long time.

Tools that help

GitHub or GitLab for hosting and pull requests. Both work fine for this workflow.
GitHub Actions or GitLab CI for automated testing. Set it up once, forget about it.
Conventional Commits if you want structured messages. I use a loose version of it.
GitLens in VS Code for visualizing branch history. Useful when you need to understand what happened.

This is how I manage Flow's codebase alone

Flow is a React and TypeScript app with a Convex backend. I work on it alone. My typical day involves two or three feature or fix branches, each lasting a few hours. I merge them into main, deploy to staging, test, and then promote to production.

The whole Git workflow takes maybe five minutes of attention per day. That is the point. Git should store your work and keep it safe. It should not become a second job.

If you are a solo founder spending energy on branch strategy, you are optimizing the wrong thing. Simplify your Git workflow until it disappears. Then spend that energy on your product.

For more on choosing a platform, see my comparison of GitHub vs GitLab. And if you want to see the full stack Flow is built on, read my guide to the tech stack for SaaS 2026.

Frequently asked questions

What Git workflow should a solo developer use? Trunk-based development with one main branch and short-lived feature branches. Create a branch, work, commit often, open a pull request for self-review, and merge. No long-lived branches, no complex release management.

Should I use branches as a solo founder? Yes, but keep them short-lived. Branches give you a sandbox to experiment and make mistakes without polluting your main branch. Delete them after merging.

How often should I commit? Commit whenever you finish a logical piece of work, usually every ten to thirty minutes. Push at least once per coding session. There is no cost to frequent commits, and the history is easier to read.

Should I write pull requests for myself? Yes. The act of reviewing your own diff catches mistakes. It also creates a record of changes that is useful when debugging later. You do not need a template, just a short description of what changed and why.

Is it okay to commit broken code to a branch? Yes, on a feature branch. That is what branches are for. Just do not merge it to main until it works and passes tests.

How do I handle hotfixes? Create a branch from the production tag, apply the fix, tag a new version, deploy it, and merge the fix back to main. Do not maintain a separate production branch.

My verdict

Solo founders need a Git workflow that protects their code without adding ceremony. One main branch, short-lived feature branches, clear commit messages, and self-reviewed pull requests. That is all. Everything else is overhead you do not need until you have a team.