Skip to main content
What is branching? In Git, a branch represents an independent line of development. The main (historically master) branch typically contains production-ready code that’s frequently deployed. When you need to build a new feature, fix a bug, or experiment without affecting main, you create a feature branch. A feature branch is an isolated copy of the codebase where you and your teammates can commit, iterate, and test changes before merging them back into main.
The image is a flowchart representing a Git workflow process, illustrating the steps from coding to production, including branching, committing, reviewing, approving, merging, and deployment.
Why branches matter
  • Isolation: Implement changes without risking main.
  • Collaboration: Multiple contributors can work on the same feature branch.
  • Safer releases: Code is validated by CI and peer review before merging.
  • Parallel development: Different features and fixes can be developed simultaneously.
Typical feature-branch workflow
  1. Create a descriptive branch from main.
  2. Make changes locally; commit often with meaningful messages.
  3. Push the branch to the remote repository.
  4. Open a pull request (PR) to merge the feature branch into main.
  5. CI runs automated checks (tests, linters) and reviewers inspect the code.
  6. Address feedback by updating the branch and pushing additional commits.
  7. Once CI passes and reviewers approve, merge the branch into main.
  8. Deploy main to staging or production as your release process requires.
Common Git commands for this flow:
Merge strategies
  • Merge commit: preserves all commits and creates a merge commit (git merge).
  • Squash-and-merge: combines all branch commits into a single commit on main.
  • Rebase-and-merge: rewrites branch commits on top of main to create a linear history.
Table: Branch types and use cases Best practices
  • Use short, descriptive branch names, e.g. feature/login-form, fix/calc-bug-123.
  • Keep main deployable at all times.
  • Run CI locally (or via pre-commit hooks) to reduce failing checks in PRs.
  • Keep branches up to date with main by merging or rebasing regularly to minimize conflicts.
  • Prefer small, focused pull requests for easier review.
Use clear, short branch names (for example feature/login-form or fix/calc-bug-123) and keep main deployable. Run CI locally (or via pre-commit hooks) before pushing to reduce noisy failures in pull requests.
Avoid rebasing branches that are already pushed and shared with others unless your team agrees—rewriting history can disrupt collaborators. Use merge for shared branches, or coordinate a force-push after rebasing.
Keeping branches healthy
  • Regularly merge or rebase changes from main into your feature branch.
  • Address CI failures quickly and update the PR with fixes.
  • Use branch protection rules (required reviews, required status checks) to enforce quality gates.
Links and references Summary Branching is a core Git workflow that enables safe, parallel development and a controlled review-and-merge process so main remains stable and ready for deployment. Follow naming conventions, keep branches current with main, and use CI and code reviews to ensure high-quality merges.

Watch Video