TickYouOff
Back
🌿

Setting Up Git Workflow and Branching Strategy

Medium 20 items · 45 min
testuser's avatar
testuser Published 1 month ago

This checklist guides teams through choosing and enforcing a Git branching model, naming rules, PR and merge policies, and commit message checks. It’s for engineers, team leads, and repo owners who want a clear, maintainable Git workflow.

Progress
0 / 20
  1. Choose branching model — Pick the model that fits your release cadence and team size.
  2. Evaluate GitHub Flow — Simple feature branches + short-lived PRs, good for continuous deploy.
  3. Evaluate Gitflow — Structured releases with long-lived release and hotfix branches.
  4. Evaluate trunk-based development — Short-lived branches, feature flags, and frequent integration to main.
  5. Define branch naming convention — Create clear prefix rules and examples for all branch types.
  6. Adopt prefix rules (feature/, fix/, chore/) — Standardize prefixes to identify purpose at a glance.
  7. Include ticket or issue IDs in branch names — Use PROJ-123 or #123 to link branches to work items.
  8. Create a pull request (PR) template — Include description, checklist, testing steps, and linked issues.
  9. Set required reviewers and review rules — Decide on number of reviewers, review scope, and approval rules.
  10. Add a CODEOWNERS file to auto-request reviewers — Map paths to teams to ensure consistent reviewer assignment.
  11. Choose repository merge strategy — Decide between merge commits, squash, or rebase for your history.
  12. Prefer squash merges for feature PRs — Use squash to keep main history linear and grouped by PR.
  13. Protect main (or trunk) branch — Enable protections: require PR, disallow force pushes, and block direct commits.
  14. Require passing CI and status checks before merge — Block merges until tests and linters pass on the PR branch.
  15. Enforce semantic commit messages — Adopt a commit message convention (Conventional Commits, etc.).
  16. Add commit-msg hook with commitlint — Use husky or native hooks to validate messages before commit.
  17. Enable automatic deletion of merged branches — Turn on repo setting or a cleanup action to remove merged branches.
  18. Document the workflow and examples in the repo — Add README section with diagrams, commands, and examples.
  19. Announce the workflow and run a short onboarding — Share docs, hold a demo, and answer team questions.
  20. Review and iterate the workflow regularly — Collect feedback after a release and adjust rules quarterly.
Sign in to save
📝 My Notes