Feature-Branch Workflow and Best Practices

The Feature-Branch Workflow

The feature-branch workflow is the standard at most professional teams including CPCODELAB. main is always deployable. All work happens on short-lived feature branches that are reviewed and merged via pull requests.

Daily Workflow Checklist

1. Start the day: git fetch origin then git rebase origin/main on your branch.
2. Work in small, focused commits — one logical change per commit.
3. Push to your remote branch frequently: git push after every meaningful commit.
4. Before opening a PR: rebase, run the test suite, review your own diff on GitHub.
5. After your PR is merged: git switch main, git pull, delete the old branch.

Best Practices Summary

• Commit early, commit often — small commits are easier to review, bisect, and revert.
• Pull (or fetch + rebase) often — stay close to main to minimise conflict surface.
• Never commit secrets — .env files, API keys, and passwords never belong in Git.
• Write meaningful messages — future-you and your teammates will thank you.
• Keep branches short-lived — long-running branches diverge and become painful to merge.
• Review your diff before committing — git diff --staged catches embarrassing mistakes.
• Use `--force-with-lease` not `--force` — safer when force-pushing feature branches.

git bisect — Finding Bugs with Binary Search

When a bug appears and you don't know which commit introduced it, git bisect performs a binary search through history. You mark a known-good commit and a known-bad commit, and Git checks out the midpoint for you to test.

git bisect start
git bisect bad                 # current commit is broken
git bisect good v1.0.0         # v1.0.0 was fine
# Git checks out a middle commit — test it, then:
git bisect good                # or: git bisect bad
# Repeat until Git identifies the first bad commit
git bisect reset               # return to HEAD when done