How to Use Git Branches for a Personal Project

Git branches let you work on a new idea without disturbing the version of your project that already works. For a personal project, a simple branch routine can make experiments safer, make mistakes easier to undo, and keep your development history understandable.

What a Git branch is

A Git branch is a movable label pointing to a commit. The default branch is commonly named main, and it usually represents the most stable version of the project. When you create another branch, Git gives you an independent line of work based on the current commit.

Branches do not normally duplicate your entire project folder. Git stores commits efficiently and changes which commit your working directory follows. You can therefore create branches frequently without creating a full copy of the repository each time.

A useful personal-project setup might look like this:

Branch	Purpose	Typical examples
main	Stable project state	Working application or published site
feature/...	New functionality	feature/dark-mode
fix/...	Bug correction	fix/login-validation
experiment/...	Temporary exploration	experiment/new-layout

The names are conventions, not rules. The important part is that each branch has a clear purpose.

Check your repository before creating a branch

Open a terminal in your project directory and inspect the current state:

git status
git branch

git status tells you which branch you are on and whether you have modified, untracked, or staged files. git branch lists your local branches; the current branch is marked with an asterisk.

Before branching, decide what should happen to existing changes. You have three common options:

• Commit the changes if they are a coherent piece of work.
• Temporarily stash them if they are unfinished but you need a clean directory.
• Leave them in place if they should also be part of the new branch and Git allows the operation safely.

For a predictable workflow, commit work that is complete enough to describe:

git add .
git commit -m "Describe the current change"

Use a focused commit message such as Add project settings form, not a vague message like Updates. A personal project does not require an elaborate commit policy, but clear messages make it much easier to find an earlier working state.

Create and switch to a branch

The modern command for creating and entering a branch is:

git switch -c feature/dark-mode

This creates feature/dark-mode from the commit you currently have checked out and switches your working directory to it. Confirm the result:

git branch --show-current
git status

You can also use the older, widely supported equivalent:

git checkout -b feature/dark-mode

Both commands perform the same basic task. git switch is more explicit because it is designed for changing branches, while git checkout can also restore files and perform other operations.

Choose branch names that are short, lowercase, and descriptive. Slashes help group related work visually, so names such as feature/search, fix/mobile-menu, and experiment/sqlite-cache are easy to scan. Avoid names that describe only a date or a vague action, such as new-stuff.

Make changes and commit regularly

Once you are on the new branch, edit your files normally. A practical cycle is:

1. Make one small, related change.
2. Run the project or its available checks.
3. Review the changed files.
4. Commit the change when the project is in a sensible state.

Inspect differences with:

git diff
git status

Stage only the files that belong to the change when possible:

git add src/theme.css src/app.js
git commit -m "Add dark mode toggle"

If you intentionally want to stage all changes, use git add ., but review git status first. This helps prevent accidentally committing environment files, generated output, credentials, or unrelated edits.

A branch can contain several commits. You do not need to wait until an entire feature is finished before committing. Frequent commits create useful recovery points. They also make it easier to identify which part of a change introduced a problem.

Do not commit secrets such as API keys, private certificates, or production passwords. Add appropriate files to .gitignore, and remember that removing a secret in a later commit does not necessarily remove it from the repository’s history. If a credential was exposed, revoke or rotate it.

Move between branches safely

Switch back to the stable branch with:

git switch main

Return to your feature branch with:

git switch feature/dark-mode

Git may prevent switching if your uncommitted changes would be overwritten. That protection is useful. Do not force the switch unless you fully understand which work will be discarded.

If the changes are unfinished, stash them temporarily:

git stash push -m "Partially finished dark mode work"
git switch main

Later, return to the original branch and restore the stash:

git switch feature/dark-mode
git stash list
git stash pop

A stash is convenient for short-term work, but it is not a permanent backup or a replacement for commits. If the work matters, make a temporary commit instead, even if you later clean up the branch history.

To see a compact history across branches, use:

git log --oneline --decorate --graph --all

This shows where branches point and how their commits relate. It is especially helpful when you are unsure whether a feature branch started from the latest main commit.

Update your branch before merging

When your feature is ready, first inspect the current state of main:

git switch main
git pull --ff-only

The --ff-only option avoids creating an unexpected merge commit when pulling from a remote repository. If you are working entirely locally and have no remote, updating is not necessary.

Then return to your feature branch. You can incorporate the latest main changes in two common ways.

Merge main into your branch

git switch feature/dark-mode
git merge main

Merging preserves the existing branch history and may create a merge commit. It is straightforward and safe for most personal projects.

Rebase your branch onto main

git switch feature/dark-mode
git rebase main

Rebasing moves your feature commits so they appear after the latest main commit, producing a more linear history. It rewrites commit identities, so be cautious if the branch is already shared with someone else or used by automated systems.

For a solo project, either approach is reasonable. Choose merge when you want the least surprising history and rebase when you prefer a clean, linear sequence. Do not repeatedly switch between strategies without a reason; consistency reduces confusion.

Merge a completed branch

After reviewing the changes and confirming that the project works, merge the branch into main:

git switch main
git merge --no-ff feature/dark-mode

The --no-ff option records a merge commit even when Git could move main forward directly. This keeps the feature boundary visible in the history. If you prefer the simplest possible history, omit it:

git merge feature/dark-mode

Before merging, consider checking:

• Does the application start or build successfully?
• Did you review git diff main..feature/dark-mode?
• Are temporary files, debug statements, and local configuration excluded?
• Does the feature work in the situations that matter for your project?
• Is the commit history understandable enough to revisit later?

If a merge conflict occurs, Git marks the affected files. Open each file and look for sections like these:

<<<<<<< HEAD
Version from main
=======
Version from feature/dark-mode
>>>>>>> feature/dark-mode

Edit the file so it contains the intended final content, remove the conflict markers, then stage and complete the merge:

git add path/to/resolved-file
 git commit

The extra leading space before git commit should not be used; the command is simply:

git commit

Git may open an editor with a suggested merge message. Save and close it, or provide a message directly when appropriate. If you realize the conflict is too complicated and want to cancel the merge before committing, use:

git merge --abort

Delete, rename, and preserve branches

After a successful merge, remove the local feature branch:

git branch -d feature/dark-mode

The lowercase -d is deliberately cautious: Git refuses to delete the branch if it contains commits that are not merged. To delete an unmerged branch intentionally, use -D, but only after confirming that the work is no longer needed:

git branch -D experiment/old-layout

Rename the current branch with:

git branch -m better-branch-name

Rename another local branch with:

git branch -m old-name new-name

Deleting a branch does not immediately erase the commits if another branch or repository reference still points to them. However, you should not treat that behavior as a backup plan. Push important work to a remote repository or create a separate backup when appropriate.

Use remote branches for backup and collaboration

If your repository has a remote named origin, publish a new branch with:

git push -u origin feature/dark-mode

The -u option records the upstream relationship, so later you can usually run:

git push
git pull

List local and remote branches with:

git branch --all

A remote is useful even for a solo project because it provides an off-device copy and lets you work from more than one computer. Still, a remote repository should not automatically be considered private. Review its visibility, access settings, and any files you push.

If a remote branch has been merged and you want to remove it:

git push origin --delete feature/dark-mode

Do this only when you are sure the remote branch is no longer needed.

Troubleshooting common problems

If Git says you have local changes that would be overwritten, inspect git status. Commit, stash, or intentionally discard the changes. To discard changes to a tracked file, use caution with:

git restore path/to/file

This removes uncommitted changes in that file and may be difficult to recover.

If a branch appears to be missing, list all branches:

git branch --all

You may be looking for a remote branch. Fetch current remote references with:

git fetch --prune

If a merge reports conflicts, resolve every marked file and run git status to see what remains. Do not commit until the conflict markers are gone.

If you committed to the wrong branch, do not panic. If the commit has not been shared, you can often switch to the intended branch and move the commit with git cherry-pick <commit-id>. First find the identifier using git log --oneline. If the mistake is more complicated, make a backup branch before changing history:

git branch rescue/wrong-branch

If you cannot remember which branch contains a change, search the history:

git log --all --oneline --decorate -- path/to/file

A simple routine that scales

For a personal project, this workflow is usually enough:

1. Keep main in a usable state.
2. Start each distinct task with git switch -c feature/short-description.
3. Commit small, related changes with clear messages.
4. Review the branch and update it from main before merging.
5. Resolve conflicts deliberately and check the result.
6. Merge the completed work into main.
7. Push important branches to a remote when you need backup or access elsewhere.
8. Delete branches that are finished, while preserving any branch that still contains valuable unfinished work.

Branches are most useful when they match the way you think about the work. Use them for features, bug fixes, experiments, and risky upgrades, but avoid creating a branch for every tiny edit. The goal is a project history that gives you safe choices: you can experiment freely, return to a known-good commit, and understand how the current version was built.