When working alone on a small hobby project, do you usually commit directly to main or create a separate branch for each feature? Creating a branch, choosing a name, merging it back, switching to main, and checking that nothing broke can feel like unnecessary overhead when the goal is to move quickly. I'm wondering where other solo developers draw the line and whether branching still provides enough value for documentation, experimentation, testing, or switching between tasks.
4 Answers
I use one main branch for prototypes and early experimentation, then introduce feature branches once the project becomes important enough that history, rollback, and maintenance matter. The overhead of creating and merging a branch is small, but it’s also perfectly reasonable to skip it for a tiny personal project where you’re comfortable reverting commits if something goes wrong.
A practical middle ground is to keep main stable and branch only when the work is substantial or likely to break things. You can also run tests automatically on every commit or on merges, which removes much of the manual checking. For unfinished work, keep it on its branch; then you can return to main for a quick fix without having half-built code mixed into the stable version.
For a solo project, I normally stay on main unless I’m doing a risky rewrite, destructive experiment, or a large feature. In those cases a branch gives me a safe place to make a mess. There’s no need to copy a team workflow if it doesn’t help you; Git should match the project’s size and complexity.
I usually use feature branches, even when working alone. They make it easier to isolate work, experiment, switch between tasks, revert changes, and understand the project history later. The branch can be tiny—even a single complete commit—and it can be deleted after merging. A little structure now is useful when life interrupts the project or you return to it months later.

That’s my approach too. Small changes go straight to main, while exploratory work gets isolated so I can compare versions or throw it away without disturbing the stable code.