TickYouOff
Sign in
Back
🔀

Git Workflow Best Practices

Medium 20 items · 30 min
testuser's avatar
testuser Published 4 weeks ago
Technical

This checklist condenses practical Git workflow rules for teams and individual developers. It covers branch naming, commit message standards, PR preparation, rebase vs merge choices, and branch protection to keep your repository healthy and reviewable.

Progress
0 / 20
  1. Adopt a clear branch naming convention — Agree on prefixes and separators team-wide
  2. Prefix feature branches with feature/ (e.g., feature/ABC-123-short-desc) — Include ticket ID and a short description
  3. Prefix bugfix branches with fix/ (e.g., fix/ABC-123-short-desc)
  4. Use release/, hotfix/, or chore/ for releases, urgent fixes, and maintenance
  5. Create new branches from the correct base branch — Branch off main or develop per your team's branching model
  6. Write concise, descriptive commit messages — Keep subject <=72 chars and start with a verb
  7. Start commit subject with a verb and include ticket ID — Example: 'Add login validation (#123)'
  8. Explain the reason in the commit body when necessary — Describe why the change was made, not just what
  9. Make small, single-purpose commits — One logical change per commit eases review and rollback
  10. Run tests and linters locally before committing — Fix obvious issues to keep CI builds green
  11. Decide when to rebase vs merge according to team policy — Document the team's choice and use it consistently
  12. Rebase your feature branch onto the latest base to keep a linear history — Rebase locally, resolve conflicts, and run tests afterwards
  13. Use merge commits to record integration points or preserve history — Prefer merge commits for long-lived branches or releases
  14. Open a Pull Request with a clear title and summary — Summarize changes, link tickets, and list breaking changes
  15. Fill the PR template: summary, testing steps, and rollback plan — Use the project PR template to standardize required info
  16. Request reviewers and assign code owners as needed — Ask specific reviewers and include domain experts
  17. Ensure CI checks and required approvals pass before merging — Wait for a green build and mandated reviewer approvals
  18. Squash or clean up commits before final merge — Use interactive rebase or squash merge to tidy history
  19. Protect main branches: block direct pushes and require PRs & checks — Enable branch protection rules and required status checks
  20. Delete stale branches after merge and keep the repo tidy — Remove merged branches locally and remotely; update tracking
Sign in to save
📝 My Notes