Git Workflow Standards Checklist (2026)

0 of 19 completed

0%

Branching Strategy

How you branch determines how you integrate. Choose a strategy and make it explicit.

Document your branching strategy in the repository READMEcritical

Whether you use trunk-based development, GitHub Flow, or Gitflow, write it down. Include: where to branch from, how long branches should live, and how to handle releases. New team members shouldn't have to guess.

Keep feature branches short-lived (under 2 days)critical

Long-lived branches accumulate merge conflicts and integration risk. Target branch lifespan under 2 days for most changes. Use feature flags for work that takes longer to complete.

Branch from and merge back to main (or develop)important

Avoid branching from other feature branches — this creates complex dependency chains. Always branch from the main integration branch and merge back to it.

Use consistent branch naming conventionsimportant

Adopt a pattern like: feature/TICKET-123-brief-description, fix/TICKET-456-bug-name, chore/update-dependencies. This makes branch purpose clear at a glance and enables automated tooling.

Delete branches after mergingimportant

Configure your git platform to auto-delete branches after PR merge. Stale branches clutter the repository and confuse developers about what's active.

Commit Conventions

Consistent commits make git history useful for debugging, reporting, and changelog generation.

Adopt Conventional Commits formatimportant

Use the format: type(scope): description. Types: feat, fix, refactor, test, docs, chore, ci. Example: 'feat(auth): add token refresh logic'. This enables automated changelog generation and semantic versioning.

Write commit messages in imperative moodimportant

Write 'Add user authentication' not 'Added user authentication'. Think of it as completing the sentence: 'This commit will...' This is the Git project's own convention.

Keep the first line under 72 charactersimportant

The first line is the summary that appears in git log, GitHub, and reporting tools. Keep it concise. Add details in the commit body (after a blank line) if needed.

Reference ticket numbers in commitsimportant

Include the ticket/issue number in the commit message: 'feat(payments): add invoice PDF export [PROJ-789]'. This creates traceability from code to requirements and powers reporting tools.

Make atomic commits (one logical change per commit)nice-to-have

Each commit should represent one logical change. Don't mix a bug fix, a refactor, and a new feature in one commit. Atomic commits make git bisect useful and rollbacks precise.

Pull Request Standards

PRs are the unit of code delivery. Standardize them.

Require a PR for all changes to maincritical

No direct pushes to main. Every change goes through a PR with at least one review. Configure branch protection rules to enforce this.

Require CI to pass before mergecritical

Configure branch protection to require status checks (tests, lints, security scans) to pass before a PR can be merged. Never allow merging with failed checks.

Use a PR description templateimportant

Create .github/PULL_REQUEST_TEMPLATE.md (or equivalent) with sections: What changed, Why, How to test, Risks. This ensures every PR has context for reviewers.

Target PR size under 200 lines changedimportant

Small PRs get reviewed faster, have fewer bugs, and are easier to revert. Track average PR size and address it if the median exceeds 300 lines.

Choose a merge strategy and stick to itimportant

Squash and merge (clean history, one commit per PR), merge commit (preserves branch history), or rebase and merge (linear history). Pick one team-wide. Squash merge is the most common for its simplicity.

Release & Deployment

How code gets from main to production.

Tag releases with semantic versionsimportant

Use git tags (v1.2.3) for releases. Follow semantic versioning: MAJOR.MINOR.PATCH. This enables tools to track deployment frequency and creates a clear release history.

Maintain a changelog (automated or manual)important

If using Conventional Commits, generate changelogs automatically. Otherwise, maintain CHANGELOG.md. A changelog makes it easy to see what's in each release.

Never force push to main or protected branchescritical

Force pushes rewrite shared history and cause problems for every developer who has pulled from the branch. Configure branch protection to prevent force pushes entirely.

Set up automated git reportingnice-to-have

Use Gitmore or a similar tool to automatically generate team reports from git activity. This provides visibility into delivery metrics (PR throughput, cycle time, review turnaround) without manual tracking.

Pro Tips

Expert advice

1

The best branching strategy is the simplest one your team will follow consistently. Trunk-based development is ideal; GitHub Flow is a good middle ground

2

Enforce commit conventions with a pre-commit hook (commitlint) — automated enforcement beats code review comments

3

Use Gitmore to track whether your team is following these standards: PR size, branch lifespan, and commit frequency are all measurable from git data

4

Review your git workflow standards quarterly. As the team grows, what worked for 3 people may not work for 15

5

Link this checklist in your repository README so new team members find it immediately

FAQ

Common questions

Which branching strategy should we use?

For most teams: trunk-based development (short-lived branches merged to main daily) or GitHub Flow (feature branches merged via PR). Use Gitflow only if you need to maintain multiple release versions simultaneously. Simpler is better — complex branching strategies create more problems than they solve.

Should we squash commits when merging?

For most teams, yes. Squash merging creates a clean, linear history where each commit on main represents one complete change (one PR). This makes git log readable, git bisect useful, and reporting straightforward. Teams that want to preserve granular commit history can use merge commits instead.

How do you enforce commit message conventions?

Use commitlint as a pre-commit hook (local enforcement) and as a CI check (server enforcement). The pre-commit hook gives developers immediate feedback; the CI check prevents non-conforming commits from being merged.

Do these standards apply to open source projects?

Yes, with minor adjustments. Open source projects should have more explicit PR templates (external contributors need more context), more permissive commit conventions (don't reject contributions for formatting), and documented review processes so contributors know what to expect.

More Checklists