Do I need Git if I work alone?

Absolutely. Git gives you a safety net with full history, the ability to undo mistakes, experiment on branches without risk, and deploy with confidence using tags. It's essential even for solo projects.

Should I use branches as a solo developer?

Yes. Branches let you work on new features or experiments without breaking your stable code on main. If something goes wrong, you simply delete the branch. It costs nothing and protects your working code.

How often should I commit when working alone?

Commit after each meaningful change: a new function, a bug fix, a refactor. Small, atomic commits make it easy to find when a bug was introduced and to revert specific changes without losing other work.

Should I use a remote repository for solo projects?

Yes. Pushing to a remote like GitHub or GitLab gives you a backup of your code, makes it easy to work from different machines, and prepares your project for future collaboration if needed.

What is the simplest Git workflow for one person?

Use main as your stable branch. Create a feature branch for each new piece of work. Make small commits, merge back into main when done, and tag releases. This keeps your history clean and your project organized.

Git Workflow for Solo Developers

You don't need a team to benefit from a solid Git workflow. Branches, atomic commits and tags keep your solo projects clean, safe and easy to manage.

Practice Git workflows Git glossary

gitquest — enquête

Why use branches when working alone?

Safety net

Keep main always working. Experiment on a branch: if it fails, delete it and your stable code is untouched.

Context switching

Working on a feature but need to fix a bug? Switch branches instantly. Each branch keeps its own context separate.

Clean history

Merging feature branches creates a readable timeline of what was added and when. It's easy to trace and revert.

Recommended workflow

A simple solo workflow: main + feature branches

This workflow is lightweight, effective, and scales if your project ever grows into a team.

1. main is always stable

Never commit directly to main. It should always contain code that works. This is your deployable branch.

2. One branch per feature or fix

Create a branch like feature/add-login or fix/header-bug. Work there until it's done, then merge.

3. Merge and clean up

Once a feature is complete, merge it into main and delete the branch. This keeps your branch list short and tidy.

4. Tag your releases

Use git tag -a v1.0.0 to mark important milestones. Tags let you jump back to any release instantly.

Complete solo workflow in the terminal

From project initialization to your first tagged release.

Step 1: Initialize the project

gitquest — init

# Initialize a new project

$git init my-project

Initialized empty Git repository in /home/dev/my-project/.git/

$cd my-project

# Create the first commit on main

$echo "# My Project" > README.md

$git add README.md

$git commit -m "Initial commit"

[main (root-commit) a1b2c3d] Initial commit

Step 2: Work on a feature branch

gitquest — feature branch

# Create a feature branch

$git switch -c feature/add-login

Switched to a new branch 'feature/add-login'

# Make small, atomic commits

$git add src/auth.ts

$git commit -m "Add login form component"

[feature/add-login d4e5f6a] Add login form component

$git add src/auth.test.ts

$git commit -m "Add tests for login form"

[feature/add-login b7c8d9e] Add tests for login form

Step 3: Merge and tag

gitquest — merge & tag

# Merge the feature back into main

$git switch main

Switched to branch 'main'

$git merge feature/add-login

Updating a1b2c3d..b7c8d9e (fast-forward)

src/auth.ts | 42 ++++++++++++

src/auth.test.ts | 28 ++++++++

2 files changed, 70 insertions(+)

# Tag the release

$git tag -a v1.0.0 -m "First stable release"

tag 'v1.0.0' created

# Clean up the feature branch

$git branch -d feature/add-login

Deleted branch feature/add-login (was b7c8d9e).

Commit strategy: small, atomic, meaningful

Good commits

Add login form component — one clear change

Fix header overflow on mobile — specific bug fix

Refactor auth middleware — single refactor unit

Bad commits

WIP — says nothing about the change

Fix stuff — impossible to find later

Add login, fix header, update tests — too many changes at once

Versioning tip

Use tags to mark your releases

Tags create permanent bookmarks in your history. Use semantic versioning to keep track of what you ship.

Annotated tags

git tag -a v1.0.0 -m "First release"

Includes author, date and a message. Recommended for releases.

List tags

git tag --list

See all your tagged versions at a glance.

Go back to a release

git checkout v1.0.0

Jump to any past release instantly. Perfect for debugging.

Part of the Remote & Collaboration guide

GitQuest is created by Anaïs (nouvelle fenêtre), web developer and head of education, specializing in tech training and digital accessibility.

Questions about solo Git workflows

Practice Git workflows in a safe terminal

GitQuest investigations let you practice branching, committing and tagging in realistic solo scenarios.

Start the investigations