Working as a team: branches and pull requests
Summary: in a team using Git, nobody touches the main branch directly. Every change goes through a feature branch, a pull request reviewed by at least one colleague, and a controlled merge. This lesson details the five steps of this workflow — used by 95% of modern tech teams.
1. The golden rule: the main branch is sacred
On a team project, the main branch (or master on older repositories) must always be in a deployable state. At any moment, it must be possible to launch a production deployment from this branch without risking breaking anything.
This discipline is put in place by convention (team agreement), and gets technically locked on GitHub/GitLab with branch protection rules. It then becomes impossible to push directly to main, even by accident.
2. The feature branch workflow, in five steps
It is the standard workflow in 2026, adopted by Google, Meta, Netflix, Microsoft, and almost every startup. It fits in five steps.
Let us look at each step.
Step 1 · Synchronize with main
Before starting, you fetch the latest changes from main. Otherwise, you risk working on an obsolete base and creating unnecessary conflicts.
Step 2 · Create a dedicated branch
You give the branch an explicit name. Conventions vary, but a common model is:
| Prefix | Usage | Example |
|---|---|---|
feature/ | New feature | feature/stripe-payment |
fix/ | Bug fix | fix/email-validation |
hotfix/ | Urgent production fix | hotfix/xss-login-flaw |
chore/ | Technical task with no user impact | chore/dependency-update |
docs/ | Documentation change | docs/api-v2-guide |
A clear name saves time for the whole team: in the list of open branches, everyone immediately understands what each one is about.
Step 3 · Develop with frequent commits
On the branch, you apply the cycle seen in lesson 1: edit, stage, commit, edit, stage, commit… Several times a day. Each commit stays local until you decide to push.
Step 4 · Push and open the pull request
When the feature is finished (or even "in progress but I want feedback"), you push the branch and open a pull request — the subject of the next section.
Step 5 · Review, discussion, merge
Colleagues read the code, leave comments, request adjustments. You fix, push again, answer the remarks. Once approved, the PR is merged into main.
3. What exactly is a pull request?
A pull request ("PR" for short, "merge request" or "MR" on GitLab) is a formal request to integrate one branch into another, with a discussion space.
It is the fundamental building block of modern team development. Almost no code reaches production without going through a PR.
Anatomy of a good PR:
- A title that is clear and short, often prefixed with the type (
fix:,feat:). - A description explaining why this PR exists, what it changes, how to test it.
- Small size: ideally fewer than 400 modified lines. Beyond that, review quality drops drastically.
- A single objective: one PR = one intention. If you fix a bug AND refactor AND update dependencies, open three separate PRs.
4. Code review — the real hidden benefit
The discussion part of a PR is the one that brings the most long-term value. Here is why.
An often misunderstood point: code review is not there to judge the author, it is there to improve the code. A good review is kind, constructive, and asks questions rather than imposing solutions ("What do you think of…?" rather than "You must do…").
Best practices for the PR author:
- Answer all the comments (with a fix, or with an explanation).
- Do not take the remarks personally.
- Thank the reviewers — their time is precious.
Best practices for the reviewer:
- First look at the description and the high-level changes, then the details.
- Ask questions, do not impose.
- Flag what is blocking (nice-to-have vs. must-fix).
- Approve quickly when it is good — blocking a PR for a week kills momentum.
5. The merge — three main modes
Once the PR is approved, it must be merged into main. GitHub, GitLab and Bitbucket all offer three merge modes, which produce different histories.
Recommendation in 2026: most modern web teams use squash and merge by default. Result:
- The
mainhistory stays linear and readable (one commit = one PR = one feature). - The branch's intermediate commits ("wip", "oops", "fix typo") disappear.
- Every merge produces one clean commit with the PR title as its message.
merge commit remains used for projects where granular history matters (Linux kernel, PostgreSQL). rebase and merge is rarer, reserved for those who like a perfectly linear history.
6. After the merge — the cleanup
Once the branch is merged, it has no reason to exist anymore. Deleting it frees visual space in the branch list and avoids confusion.
The big platforms have an option to "automatically delete the branch after merging" that should be enabled once and for all in the project settings.
Remember in 30 seconds
- The
mainbranch is sacred: nobody touches it directly. - Every change goes through a feature branch with an explicit name (
feature/…,fix/…). - A pull request is opened to request the merge, with title + description + tests + review.
- Code review catches bugs, trains juniors, spreads knowledge. It is the real treasure of the workflow.
- Merging is generally done with squash and merge to keep a clean
mainhistory. - After merging, you delete the branch to stay organized.