# My Git Workflow for Solo Projects (That Scales to Teams)
By Govind Bajaj · 2024

Tags: git, workflow, methodology, version-control, software-engineering
I use the same Git workflow for solo side projects and team production apps. One convention. Zero merge conflicts. Here's the branch strategy and commit discipline.
I use the same Git workflow for solo side projects and five-person team production apps.

One convention. Zero merge conflicts in six months. Clear history that tells the story of the project. And the ability to figure out why any line of code exists within thirty seconds.

Here is the branch strategy and commit discipline that makes this possible.

## The Branch Strategy: Main, Feature, Hotfix

Three branch types. No exceptions.

main: Always deployable. Protected branch — no direct pushes. Every commit on main has been reviewed.

feature/description: All new work. Created from main. Merged back to main via pull request. Deleted after merge.

hotfix/description: Production emergencies only. Created from main. Merged to main immediately after verification.

That is it. No develop branch. No release branches. No long-lived feature branches. Simplicity scales better than complexity.

## Branch Naming

Consistent naming makes branch purpose clear at a glance:

feature/add-razorpay-webhook feature/refactor-order-service fix/n1-query-product-list hotfix/payment-signature-verification

The prefix (feature, fix, hotfix) tells you the branch type. The description tells you what it does. No ticket numbers in branch names — those belong in commit messages and PR descriptions.

## Commit Message Discipline

I follow conventional commits. The format is:

type(scope): description

Types: feat (new feature), fix (bug fix), refactor (code change with no behavior change), docs (documentation), test (adding tests), chore (maintenance).

Examples:

feat(payments): add Razorpay webhook handler fix(orders): resolve N+1 query in product list refactor(auth): extract JWT verification to middleware docs(readme): add deployment instructions

The scope is optional but recommended. It tells you which part of the codebase changed without reading the diff.

## Commit Size

Each commit should do one thing. A commit that adds a feature and fixes a bug is two commits. Split them.

Why: Clean history makes bisecting possible. If a bug appears, you can binary search through commits to find the exact change that introduced it. Mixed commits make this impossible.

## The PR Template

Every pull request answers three questions:

What: What does this PR change? Why: Why is this change needed? How: How was it implemented?

```markdown
## What
Adds Razorpay webhook handler for payment confirmation

## Why
Current implementation polls for payment status every 5 seconds.
Webhooks give us instant confirmation and reduce server load.

## How
- Created POST /api/webhooks/razorpay endpoint
- Added signature verification using HMAC-SHA256
- Updated order status on successful payment
- Added webhook event logging for audit trail
```

## Solo Project Adaptations

For solo projects, I skip the PR review but keep everything else. I still create feature branches. I still write conventional commits. I still use PR descriptions (as commit descriptions when merging).

The discipline of describing what I am doing before merging forces me to think about whether the change is correct and complete.

## Takeaways

- Three branch types: main, feature, hotfix — no exceptions
- Use conventional commits (feat, fix, refactor, docs, test, chore)
- Each commit does one thing — mixed commits prevent bisecting
- Every PR answers What, Why, and How
- Keep feature branches short-lived — merge within a few days
- Delete merged branches immediately — they are noise in the branch list
- This workflow scales from solo projects to teams of any size
- Git discipline is not bureaucracy — it is communication with your future self