DEV Community

Cover image for Code Reviews Suck. Here’s What Helped (and Where It Can Break)
Mihir Srivastava
Mihir Srivastava

Posted on

Code Reviews Suck. Here’s What Helped (and Where It Can Break)

#codereview #git #bitbucket #webdev

I missed one line during a code review, and the universe promptly punished me.

Analytics exploded. Metrics vanished. I basically broke half the reporting dashboard over what felt like a missing semicolon. One small oversight, and it was like I'd hit the self-destruct button on the team’s trust.

That’s when I realized something: the way we do code reviews isn’t just painful—it’s dangerously optimistic. We assume smart people will always catch things, but we're humans, not diff-parsing robots.

So I rethought how I can improve this process. Not out of inspiration, but sheer panic.

The Problem With Big PRs

My first attempt at a fix was pretty straightforward: no PRs over 10–15 files. The smaller the diff, the easier the review.

That worked. Until someone submitted a 90-file PR.

Clearly, we needed something more sustainable.

What I Wanted From the Workflow

  • Reviews that are actually doable
  • Development that keeps moving
  • No one getting blocked waiting for approval

The Workflow That Helped

This isn’t a silver bullet, but here’s the setup that made things more bearable:

1. Start With a Core Feature Branch

This is your main branch for the entire feature. You start with a local branch that ties to your Jira ticket or GitHub issue.

Example:

  • Create a branch: 
git checkout -b feature/checkout-flow
Enter fullscreen mode Exit fullscreen mode

This branch becomes your personal workspace. All your work lives here. It doesn’t get pushed directly.

2. Commit Locally, Task by Task

Work on tasks one at a time, and commit each individually.

For example:

 git add .
 git commit -m "Add form validation for checkout"
Enter fullscreen mode Exit fullscreen mode

This way, each commit is atomic and meaningful. You keep working in the same local branch.

3. Create a Branch Per Task, Cherry-Pick the Commit

When a task is ready for review:

git checkout -b task/checkout-validation
git cherry-pick <commit-hash>
git push origin task/checkout-validation
Enter fullscreen mode Exit fullscreen mode

Reviewers now get a clean, focused diff.

4. Apply Review Feedback in the Task Branch

If there’s feedback:

  • Make the changes 
git add .
git commit --amend
git rebase feature/checkout-flow
git push --force
Enter fullscreen mode Exit fullscreen mode

This keeps the PR clean and up to date.

5. Merge Back Into Your Feature Branch

Once the task PR is approved:

git checkout feature/checkout-flow
git merge task/checkout-validation
Enter fullscreen mode Exit fullscreen mode

Repeat this process for each task until the full feature is built and reviewed.

Visualizing the Flow

Here's what the workflow looks like:

feature/checkout-flow
|
|-- commit A (task: form validation)
|-- commit B (task: UI tweaks)
|-- commit C (task: error handling)
Enter fullscreen mode Exit fullscreen mode

Branches for review:

task/checkout-validation -> cherry-pick A
task/ui-tweaks -> cherry-pick B
task/error-handling -> cherry-pick C
Enter fullscreen mode Exit fullscreen mode

Once each PR is approved, merge them back into feature/checkout-flow, which now has fully reviewed commits.

Why This Works (When It Works)

  • You’re not blocked by pending reviews
  • Reviewers only see what’s relevant
  • Commits stay focused and small
  • Your local branch is your single source of truth

But It’s Not Perfect

This workflow has real benefits, but also some rough edges:

1. Cherry-Picking Can Get Messy

Cherry-picking introduces risk:

  • It’s easy to forget syncing changes
  • You might fix something in a task branch but forget to update your local feature branch

That can lead to silent bugs or weird conflicts later.

2. Assumes Git Fluency

You need to be comfortable with cherry-picking, rebasing, and force-pushing.

If your team isn’t confident with Git, this can create friction.

3. Too Many Small PRs Can Be a Drain

Small PRs are great, but too many at once can overwhelm reviewers.

  • Review fatigue is real
  • Hard to see how the parts fit into the whole

4. Tooling Might Not Keep Up

Some systems don’t handle this branching model well:

  • CI/CD may struggle with cherry-picked branches
  • GitHub/Jira linking becomes noisy or unclear

When This Workflow Works Best

✅ Great when:

  • Teams are comfortable with Git
  • CI is fast and tooling is flexible
  • You want atomic, clean reviews

🚫 Painful when:

  • Teams are large and less Git-savvy
  • Your CI setup is slow or clunky
  • You need to keep PRs tightly linked to tickets

What Do You Do?

This workflow has saved me more than once, but I’m always curious:

  • How do you manage big features across multiple PRs?
  • Do you stack PRs? Use feature flags? Preview branches?
  • Have you solved review bottlenecks a different way?

Drop a comment — I'd love to hear your process.

Thanks for reading. If this helped or gave you ideas, feel free to share. Maybe together we can make code reviews suck a little less.

Top comments (0)