Teamwork: PRs, review, and conventions — Git and teamwork

Workflows

A workflow is the rules for how the team brings changes to production. Two modern and simple ones:

GitHub flow: main is always deployable. For each change you create a short branch, open a Pull Request, it gets reviewed, merged, and deployed.
Trunk-based development: everyone integrates very often (several times a day) into a single main branch (main/trunk) with very short-lived branches. It avoids long-lived branches that diverge and cause painful merges.

Both share the same idea: small, short-lived branches, and frequent integration.

git switch -c feature/cart
# ... commits ...
git push -u origin feature/cart   # push the branch to the remote

Pull Request (PR)

A Pull Request (or Merge Request) is a request to merge your branch into another (usually main). It's not a Git command: it's a feature of the platform (GitHub/GitLab) that adds, on top of the merge, a review space:

it shows the full diff of the changes,
it allows line-by-line comments and discussion,
it runs the CI (tests, lint, build) automatically,
it records approvals before you can merge.

Code review is the review by another person: it catches errors, shares knowledge, and keeps quality up. You ask for approval, address the comments, and only then is it merged.

Conventional Commits

Conventional Commits is a convention for commit messages with a fixed format, readable by machines and humans:

<type>[optional scope]: <description>

[optional body]

[optional footer, e.g. BREAKING CHANGE: ...]

Common types:

git commit -m "feat: add filter by category"   # new feature
git commit -m "fix: correct the total calculation"   # bug fix
git commit -m "docs: update the README"
git commit -m "refactor: extract the payments service"
git commit -m "test: cover the empty cart"
git commit -m "chore: update dependencies"

An incompatible change (breaks the public API) is marked with ! or with a BREAKING CHANGE: footer:

git commit -m "feat!: change the signature of createUser"

Advantage: it lets you generate the changelog and decide the version bump (semver) automatically from the messages.

Branch protection and CODEOWNERS

In teams, main is protected so nobody can break it. Typical rules:

forbid direct push: everything enters through a PR;
require N approvals before merging;
require the CI to pass (tests/lint green);
forbid force-push and branch deletion.

The CODEOWNERS file defines who is responsible (mandatory reviewer) for each part of the code. When those files are touched, their owner is added automatically as a reviewer of the PR:

# .github/CODEOWNERS
*.ts            @frontend-team
/infra/         @devops-team
/src/payments/  @ana @luis