Laravel Git Blog - Reviews

Branch Protection Rules That Stick

Wed, 21 Oct 2026 00:00:00 GMT

Branch protection fails in two ways: too little of it, and so much of it that the team routes around it. For a small team, three rules do most of the work.

1. Require a pull request and one review

Nobody pushes straight to main, including the senior who "just fixes a typo". One reviewer is enough at this size — the point is a second pair of eyes, not a committee.

2. Require checks to pass

The test suite runs on the PR and must be green before merge. This is what keeps "main always runs" true in practice rather than in principle. If the suite is slow, fix the suite — do not downgrade the rule to "tests optional".

3. No force-pushes to main

Shared history is append-only. Rewriting main breaks everyone's clones and makes the audit trail meaningless. Rebasing stays on feature branches, where it belongs.

What to leave out until it hurts

Code-owner reviews, signed-commit requirements, linear-history-only, status checks from five tools — each adds friction that makes sense at a specific size or risk level. Add them when a real incident names the need, not because the settings page offers them.

The test of a ruleset is whether the team still respects it in month six. Small and enforced beats thorough and bypassed.

Merging vs Rebasing on a Small Team

Wed, 21 Oct 2026 00:00:00 GMT

Few git arguments cost more than they settle. The working rule for a small team fits in one sentence: rebase your own branch, merge into main.

Rebase is for your branch

While your branch is still yours, keep it current and readable:

git fetch origin
git rebase origin/main

Your commits replay on top of main, conflicts show up in small pieces while you still remember the change, and the branch reads like a story a reviewer can follow.

Merge is for main

When the branch is done, merge it. The merge commit marks where the work landed and keeps the group's shared history untouched:

git checkout main
git merge --no-ff pr-42-branch

--no-ff keeps the feature visible as one unit, which makes the changelog draft and any later revert much easier.

What not to do

Never rebase a branch someone else has pulled. Rewriting shared history is how teammates lose work and trust the repo a little less. If it is pushed and shared, it merges.

That is the whole policy. Write it in the README and spend the argument on the code instead.

Migrations in Code Review: What to Look For

Wed, 21 Oct 2026 00:00:00 GMT

Most code review feedback is a request for changes, and the author edits the same file. Migrations break that rule: once a migration is merged and run anywhere - staging, a teammate's machine, production - the file is a fact. Editing it changes nothing that already ran and silently forks the databases that have not. Reviewing migrations well matters more than reviewing almost any other diff, because it is the last time the change is cheap.

The review checklist

Does down() actually reverse the up()? A down() that drops the table when up() added a column is a trap for the next rollback. If the change is genuinely irreversible - a dropped column - that should be a shouted comment, not a silent absence.

Are defaults and nullability safe for existing rows? Adding a NOT NULL column without a default to a table with a million rows either fails or rewrites the table while holding a lock. The safe shape is nullable first, backfill, constrain later - the same three-step dance as zero-downtime deploys require.

Did new query paths get indexes? A column added for a lookup (WHERE stripe_customer_id = ...) without an index is a slow query waiting for traffic. The migration is the cheapest place the index will ever be added.

Is data surgery mixed into schema changes? A migration that both alters a table and rewrites its rows couples "change the shape" with "change the content" in one irreversible step. Schema in migrations, data in a one-off artisan command you can rerun and monitor.

After merge: hands off

The corollary rule, worth stating in the team's written workflow: a merged migration is never edited. Found a typo in a column name after merge? A new migration renames it. This feels heavy the first time and is obviously correct the first time someone hits a database that ran the original.

Review migrations slowly, then let them harden into facts. That asymmetry - expensive to change, cheap to get right beforehand - is exactly what the habits in Code Review Habits That Actually Catch Bugs are for.

How to Review a Large Pull Request Without Losing a Day

Wed, 21 Oct 2026 00:00:00 GMT

The right answer to "how do I review a 2,000-line pull request" is usually "ask for three smaller ones" - and small pull requests get reviewed faster makes that case. But sometimes the split is not happening: it is a generated migration plus its fallout, a vendored update, a refactor that only makes sense whole. Here is how to review it honestly anyway.

Read in this order

1. The description and the tests, before any source. The description tells you what the author thinks they did; the tests tell you what the code claims to guarantee. If either is missing, that is your first comment - reviewing code whose intent you are guessing is how subtle bugs get waved through.

2. The risky files, not the first files. Sort mentally by blast radius: migrations (see reviewing migrations), anything touching auth, money or deletion, config and deploy changes. These get your freshest attention and line-by-line reading. Controllers and views get pattern-level reading. Generated files, snapshots and lockfiles get a skim - nobody reviews composer.lock line by line, they verify it was regenerated (the lockfiles guide has the drill).

3. Commit by commit, if the commits are clean. A well-sequenced history is the author's own explanation of the change - this is what tidying commits before review is for. If the commits are "wip", "fix", "fix fix", abandon this step and read the full diff.

Give feedback that fits the size

The failure mode of big reviews is binary: a defeated "LGTM" or a comment list so long it reads as hostility. The useful middle is sorting your comments:

Blocking: correctness, security, data loss. Few of these, clearly marked.
Worth discussing: design questions where you could be wrong.
Not blocking: style and preference - say once, in one comment, not forty.

And say what you did: "read migrations and billing code line by line, skimmed the rest" is honest and lets the author ask a second reviewer for the parts you skimmed. Two honest partial reviews beat one pretend complete one.

The last word stays with prevention: the best large-PR review is the one that never has to happen because the next one got split.

Review Your Own Pull Request Before Anyone Else Does

Wed, 21 Oct 2026 00:00:00 GMT

By the time you open a pull request, you have read your own code a dozen times - as its author. That is exactly the problem. You see what you meant, not what you wrote. A self-review pass, done in the diff view rather than your editor, catches the gap between the two while it is still free to fix.

Read the diff, not the code

Your editor shows the final state with all the context in your head. The diff shows only what changed, which is what your reviewer gets. Open the "files changed" view - or run it locally:

git diff main...HEAD

Read it top to bottom as if a colleague sent it. The first things that jump out are usually embarrassing in a useful way: a leftover dump() in a Laravel controller, a commented-out block, a migration that adds a column the model no longer uses.

The usual suspects

A short checklist beats good intentions:

Debug leftovers: dump(), dd(), console.log, stray log channels.
Dead code: commented blocks, unused imports, variables set and never read.
Names that made sense mid-thought: $data2, $temp, $result where the domain has a real word.
Tests that prove the happy path only - the code review habits post has the reviewer-side version of this list.
Anything you cannot explain in one sentence. If you struggle, the reviewer will too.

Annotate the non-obvious parts

Some lines are strange on purpose: a workaround for a queue driver quirk, an index added for one specific report. Leave a comment on your own PR explaining them before anyone asks. It saves a review round, and it pairs naturally with a good pull request description - the description says what and why, the inline comments say "yes, this odd line is deliberate."

Self-review also keeps the whole pipeline honest: PRs stay small and reviewable, commits stay tidy, and your reviewer's attention goes to the decisions that actually need a second brain instead of the typos that needed a second pair of eyes - yours, an hour later.

Small Pull Requests Get Reviewed Faster

Wed, 21 Oct 2026 00:00:00 GMT

A 1,500-line pull request does not take ten times longer to review than a 150-line one. It takes longer than that, because nobody starts it. Reviewers see the line count, decide they need a free afternoon they do not have, and the PR sits. Small PRs break that cycle.

Why big PRs stall

Three things happen with a large diff:

Reviewers postpone it, so feedback arrives days late, after you have mentally moved on.
When the review finally happens, it is shallow - nobody can hold 40 files in their head, so real bugs hide in the middle of the diff.
Merges get riskier, because a PR that touches everything conflicts with everything.

A PR under a few hundred lines gets read the day it opens, and it gets read properly.

Splitting a Laravel feature

Take a typical feature: a migration, a model, a controller, routes, a form request, views, tests. That feels atomic, but it usually splits cleanly:

Migration and model first - the schema is reviewable on its own.
The read path next - list and show endpoints with their tests.
The write path last - create, update, delete, and validation.

Each PR is deployable, each review is quick, and if the write path turns out to be the wrong design, you have not merged it yet. If later PRs depend on earlier ones, use stacked branches: branch the second PR off the first, and retarget it to main once the first merges.

Keeping PRs small day to day

One idea per PR. If the description needs an "and also", it is two PRs.
Split mechanical changes (a rename across 30 files, a Pint run) from behavioral ones, so the behavioral diff stays readable.
Tidy commits before opening the PR so the reviewer reads your intent, not your process - see Tidying Commits Before You Open a Pull Request.
Write a description that says what to look at first - Writing a Good Pull Request Description covers that.

The habit compounds: reviewers who trust your PRs to be small stop dreading them, and the whole team's queue moves. Pair it with the review-side habits in Code Review Habits That Actually Catch Bugs and the review round trip gets short enough to feel like pair programming at a distance.

Trunk-Based Development on a Small Laravel Team

Wed, 21 Oct 2026 00:00:00 GMT

Long-lived feature branches feel safe and bill you later: the two-week branch that takes a day to merge, and the merge nobody wants to re-run. Trunk-based development is the alternative that works well for small teams.

The rules, sized for a small team

Everything targets main. Branches live hours to a couple of days, never weeks.
Main always runs: tests pass, migrations apply, the app boots.
Review is quick and small, because the changes are small.

Half-done work still merges

The objection is always "the feature is not finished". Merge it anyway, behind a flag. In Laravel that is a config entry or a Feature::active() check, not a branch:

if (config('features.new_billing')) {
    // new flow
}

Delete the flag when the feature ships. A flag you forget is cheaper than a branch you rebase for a month.

What it buys

Conflicts stay small because diffs stay small. Main is deployable any day, so the git-push deploy from a tag or from main stops being an event. And code review gets read, because there is finally little enough of it.

Start with the rule that matters most: nothing lives on a branch longer than two days.

Writing a Pull Request Description People Actually Read

Wed, 21 Oct 2026 00:00:00 GMT

Reviewers decide how carefully to read from the description. A blank one says "good luck"; a wall of text says the same thing louder. Three short sections cover almost every PR.

What changed

One or two sentences, no file list — the diff already shows files. "Adds a queued job that re-sends failed webhook deliveries with backoff" is enough.

Why

The part that saves the reviewer a Slack message. Link the ticket if there is one, otherwise say what was broken or missing. "Deliveries failed silently when the endpoint returned 5xx, and clients had no way to replay them" is a reason; "requested changes" is not.

How to see it working

The step everyone skips and the one reviewers want most: the command to run, the page to open, the seed data to create. On a Laravel app that is usually a route to hit, an artisan command, or a test to run:

php artisan test --filter=WebhookRetryTest

Keep it short on purpose

If the description needs paragraphs, the PR probably needs splitting. Small PRs with three honest sections get read, get real comments, and merge while the context is still warm.

Reviewing Pull Requests With Git Worktrees

Tue, 20 Oct 2026 00:00:00 GMT

Reviewing a pull request properly means running it, not just reading the diff. Switching your working copy back and forth costs your uncommitted state every time. Worktrees sidestep that.

Check out the PR next to your work

git fetch origin
git worktree add ../myapp-pr-42 pr-42-branch

You get a second directory on the PR branch while your main checkout stays exactly as it was.

Give it its own environment

A Laravel app needs more than the code:

cd ../myapp-pr-42
composer install
cp ../myapp/.env .env

Then change what must not clash: APP_URL and port if you serve both at once, and DB_DATABASE to a throwaway database so the PR's migrations do not touch your dev data:

php artisan migrate --seed
php artisan serve --port=8001

Tear it down cleanly

git worktree remove ../myapp-pr-42

The branch stays until you delete it; the directory and database go.

When it pays

One PR a month is fine to stash and switch. A team merging daily needs the review to be cheap, and cheap means the PR runs in its own directory while your own work never moves.

Code Review Habits That Keep Main Clean

Thu, 15 Oct 2026 00:00:00 GMT

Review works best when it is cheap.

Keep changes small

Small changes get read. Large ones get skimmed.

Say what and why

A short description of the change and the reason saves the reviewer a guess.

Review quickly

A review that waits a week blocks the next change too.