Pull Request and Code Review on GitHub — How to Protect Branches and Collaborate Without Conflicts

Why use a pull request instead of direct merge?

We see it all the time: developers pushing code directly to main or develop without a pull request. The problem? Something inevitably breaks — an unnoticed conflict, a change that overwrites a colleague's work, a syntax error that crashes production.

At Meteora Web, we work on projects ranging from single WordPress sites to Laravel platforms with distributed teams. The difference between an organized flow and chaos is the pull request. It's not bureaucracy: it's a safety net that protects code and saves hours of debugging.

A pull request (PR) is a formal request to merge changes from one branch to another (usually from feature to main). The beauty is that someone else reviews them before accepting. This is called code review. It's not about policing: it's about improving quality, sharing knowledge, and preventing incidents.

The cost of not using PRs

A client once told us they lost an entire day because two developers edited the same file on main simultaneously. Without separate branches and PRs, the only fix was a manual merge with git log and conflict resolution. Time lost: 8 hours. Cost: hundreds of euros. With a feature branch and a PR, they'd have seen the conflict with one click and resolved it before merge.

Rule of thumb: if your team has more than one person, PRs are not optional. They are mandatory.

How to create a pull request on GitHub?

Two ways: via terminal with GitHub CLI or from the web UI. Let's start with the terminal — it's fast and integrates with Git flow.

Using GitHub CLI (gh)

Make sure gh is installed and authenticated. Then, after pushing your branch:

git checkout -b fix/login-bug
git add .
git commit -m "Fix login bug"
git push origin fix/login-bug
gh pr create --title "Fix login bug" --body "Resolves redirect issue after login. Fixes #42" --base main

The --base flag indicates the target branch. Without it, uses the default (usually main).

From GitHub web UI

After pushing the branch, GitHub shows a yellow banner inviting you to create a PR. Click, fill in title and description, select reviewers and labels, then click Create pull request.

Tip: the PR description should include the why of the change, not just the what. Example: "We moved validation to server-side because the client was unreliable. This reduces false positives and speeds up the form." More context makes review easier.

Linking issues and projects

You can link a PR to a GitHub issue by writing Closes #42 in the body. When the PR is merged, the issue closes automatically. Very useful for tracking.

How to do effective code review?

Code review is not an exam. It's a technical conversation. Goal: find bugs, improve readability, verify code follows team standards.

Review flow on GitHub

When you receive a review request:

1. Open the PR and click Files changed.
2. Read the code line by line. If the PR is huge, ask the author to split it.
3. Add comments on lines where you see issues: click on the line number and write.
4. At the end, choose an action: Comment (just observations), Approve (ok for merge), Request changes (blocks until fixes).
5. If you request changes, the developer makes additional commits on the branch. The PR updates automatically. Then you re-review.

Review checklist

• Does the code solve the described problem?
• Are there tests? If missing, it's a warning.
• Is the logic clear? Self-explanatory variable and function names?
• Are there vulnerabilities (SQL injection, XSS, hardcoded passwords)?
• Does the code follow project conventions (indentation, naming, structure)?
• Are there comments explaining why a choice was made?

We use a simple rule: no PR should stay open more than 24 hours. For small teams, one review per day. For large teams, rotate reviewers. Stale PRs create conflicts and slow releases.

What are branch protection rules and how to configure them?

Branch protection prevents direct pushes to main (or other sensitive branches). It's the mandatory complement to PRs. Without protection, someone can bypass review and push directly.

Configuring protection on GitHub

Go to repository Settings → Branches → Add branch protection rule. Enter the branch name (e.g., main). Then select:

• Require a pull request before merging — forces PRs for all changes.
• Require approvals — set minimum number of approvals (usually 1 or 2).
• Dismiss stale pull request approvals when new commits are pushed — if a new commit is pushed after approval, review expires.
• Require status checks to pass before merging — link to CI/CD (e.g., automated tests, linting).
• Restrict who can dismiss pull request reviews — only owners or admins.
• Do not allow bypassing the above settings — blocks even admins (if you want).

A real example: on a Laravel project we manage, we enabled: mandatory PR, 1 approval, automated tests via GitHub Actions. The main branch is locked. No one can push directly, not even us admins (except emergency override). This reduced accidental merges to zero.

Protecting multiple branches

Apply the same rule to develop, release/*, etc. Use patterns like release/* to cover all release branches.

Automation with GitHub Actions

Beyond static protection, add workflows that run tests, static analysis (PHPStan, ESLint), and deploy. A minimal example to run tests on every push to a feature branch:

name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install && npm test

With this, the PR cannot be merged until the test job passes (if you enable Require status checks).

What to do now

If your repository doesn't have branch protection yet, here are three immediate actions:

1. Protect the main branch: go to Settings → Branches and add a rule for main: mandatory PR, at least 1 approval.
2. Start using PRs for every change: even for trivial fixes. Get into the habit: feature branch, push, PR, review, merge. After a week it becomes automatic.
3. Create a review checklist: print it or keep it in a shared doc for the team. It helps not miss critical points.

At Meteora Web, we see teams transition from chaos to an ordered flow with just a few well-applied rules. The pull request is not a hurdle: it's your best ally for writing better, safer, and shared code. For the full picture of Git for teams, check our main guide on Git for developers — from basics to team workflows.

Remember: a protected repository is a repository that won't make you lose sleep.