Git workflows and code review

Every change enters production through version control. How you branch, review and merge decides how fast you can ship and how safely you can undo.

gitGitHub / GitLabCODEOWNERSpre-commitConventional Commitsgit worktree

Branching models

: short-lived branches (hours or a day or two) merged into main frequently, with feature flags hiding unfinished work. Best for fast feedback and .
Feature branches with pull requests: the common middle ground. Keep branches small and short.
Long-lived release branches (Gitflow style): useful when you must maintain several released versions at once; slower and more merge-heavy.
Whatever the model, main must always be releasable, and every change reaches it through a reviewed pull request.

What a good pull request is

Small: a reviewer can understand it in minutes. Large changes hide mistakes.
One purpose, with a description of why, not only what.
Green CI before review starts, so humans spend time on design and risk, not typos.
Reviewed by someone who owns the area: automates the request.
Merged with a clear history (squash or rebase merge) so that a revert is one command.

Make the rules automatic

Rules that live only in a wiki get forgotten. Encode ownership in the repository and enforce branch protection in the platform.

.github/CODEOWNERStext

# the last matching pattern wins
*                    @example/engineering
/infra/              @example/platform
/.github/workflows/  @example/platform @example/security
/src/auth/           @example/security

protect main with the GitHub CLI (requires admin rights)bash

gh api -X PUT repos/example/app/branches/main/protection --input - <<'EOF'
{
  "required_status_checks": { "strict": true, "contexts": ["verify"] },
  "enforce_admins": true,
  "required_pull_request_reviews": { "required_approving_review_count": 1, "require_code_owner_reviews": true },
  "restrictions": null
}
EOF

Habits that pay off

Commit early and often on your branch; clean up before merging.
Never rewrite history on a shared branch.
Sign commits or tags for releases when provenance matters.
Keep secrets out of history: a secret committed once must be rotated, not just deleted.
Revert first, investigate second, when main breaks.

Trunk-based developmentWorking in short-lived branches merged into the main branch frequently, hiding unfinished work behind feature flags.see in glossary →CDcontinuous delivery · continuous deploymentDelivery keeps every change deployable at any time; deployment goes further and releases each passing change to production automatically.see in glossary →CODEOWNERSA repository file that maps paths to the people or teams who must review changes there.see in glossary →

connections on the map

Git workflows and code reviewtriggersCI pipelines that stay fast

updated on 14/10/2026 · sources to go deeper · report an error

Unlocks

test what you learned

Loading questions…