A Simple Git Workflow for Small Teams (and How to Fix Mistakes)

Most developers learn just enough Git to survive: add, commit, push, and a prayer. That works until two people edit the same file, a bad commit reaches production, or someone force pushes over a teammate's work.

This guide covers a simple workflow that works well for small teams, plus the recovery commands you will need when things go wrong.

The workflow at a glance

We will use a lightweight approach often called feature branch workflow:

1. main always contains working, deployable code
2. Every change happens on its own short-lived branch
3. Changes reach main only through a pull request
4. Branches are deleted after merging

It is simple, and it prevents most team conflicts.

Step 1: Set up Git properly

Configure your identity once:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase true

Setting pull.rebase true keeps your history clean by avoiding needless merge commits every time you pull.

Step 2: Start every task on a new branch

Never work directly on main. First, update it:

git switch main
git pull

Then create a branch with a clear name:

git switch -c feature/user-login

Good branch names describe the work and use a prefix:

• feature/user-login
• fix/cart-total-bug
• chore/update-dependencies

Avoid names like test, new, or myBranch. Your teammates should understand the purpose at a glance.

Step 3: Commit small and often

A commit should be one logical change. Check what you are about to commit:

git status
git diff

Stage and commit:

git add src/auth/login.js
git commit -m "Add login form validation"

Use git add -p to stage only parts of a file. It helps you keep unrelated changes in separate commits.

Write useful commit messages

A good message explains what changed and why. Follow this pattern:

Add login form validation

Reject empty emails and passwords shorter than 8 characters
before sending the request to the API.

Keep the first line under about 50 characters, use the imperative mood ("Add", not "Added"), and never write messages like "fix stuff" or "final final v2".

Many teams also adopt prefixes such as feat:, fix:, and docs:. Pick one style and stay consistent.

Step 4: Keep your branch up to date

While you work, main moves forward. Bring in the latest changes regularly:

git fetch origin
git rebase origin/main

If a conflict appears, Git pauses and marks the files. Open them, choose the correct code, remove the conflict markers, and continue:

git add path/to/resolved-file.js
git rebase --continue

If things get confusing, you can always back out safely:

git rebase --abort

Step 5: Push and open a pull request

git push -u origin feature/user-login

Then open a pull request on GitHub, GitLab, or Bitbucket. A good pull request has:

• A clear title and a short description of what changed
• Screenshots for visual changes
• Notes on how to test it
• A small size, ideally under a few hundred changed lines

Small pull requests get reviewed faster and hide fewer bugs. If a reviewer asks for changes, commit them to the same branch and push again.

Step 6: Merge and clean up

After approval, merge through the platform. Then tidy up locally:

git switch main
git pull
git branch -d feature/user-login

Fixing mistakes: your safety net

Everyone makes mistakes. Knowing these commands removes the fear.

Fix the last commit message or add a forgotten file (before pushing):

git add forgotten-file.js
git commit --amend

Discard uncommitted changes in one file:

git restore src/app.js

Unstage a file without losing changes:

git restore --staged src/app.js

Undo the last commit but keep your work:

git reset --soft HEAD~1

Undo a commit that is already pushed and shared:

git revert <commit-hash>

revert creates a new commit that reverses the old one. It is the safe choice on shared branches because it does not rewrite history.

Save unfinished work to switch tasks quickly:

git stash push -m "half done login form"
git stash pop

Recover something you thought was lost:

git reflog

The reflog records where HEAD has pointed, including commits that no branch references anymore. It has rescued many "deleted" commits.

Rules that prevent disasters

1. Do not force push to shared branches. If you must force push your own branch after a rebase, use git push --force-with-lease, which refuses to overwrite work you have not seen.
2. Never commit secrets. Add .env to .gitignore from day one. If a secret does get pushed, rotate it immediately, because deleting the commit is not enough.
3. Protect main. Enable branch protection so nobody can push directly and pull requests need at least one approval.
4. Use a .gitignore. Keep node_modules, vendor, build folders, and editor files out of the repository.
5. Pull before you push. It avoids rejected pushes and surprise conflicts.

Final thoughts

You do not need to memorize every Git command. Learn a small, reliable workflow: branch, commit, rebase, pull request, merge. Then keep restore, revert, stash, and reflog in your back pocket for emergencies. Your team will thank you with fewer conflicts and a history that actually tells a story.

What Git mistake taught you the most? Share it in the comments.