Sign in
Log inSign up

How do you work with pull requests at work?

Ivan Bokii's photo
Ivan Bokii
·May 24, 2020

Hello friends,

I'm working on a small side-projects called PRBoard (prboard.dev). It's a dashboard for teams that host their repos on GitHub. I'm currently in the market-validation phase, and I think some of my assumptions on how this product can be helpful for teams are invalid. For this reason, I'm gathering different ways engineering teams work with pull requests.

For example, in my team, when someone creates a new pull request, they send a message on Slack about it. We rarely use GitHub's built-in "assignees" and "reviewers" features because usually, it's more than one person who can review a pull request. When someone picks a PR, they usually leave an emoji on the original slack message signalling that they're starting the review.

There's a couple of downsides to the described approach:

  1. No clear picture of all currently open PRs from my team. We structure code as one big monorepo with multiple teams working on separate code paths. This makes using GitHub's pull requests page almost impossible.

  2. No way to know when a pull request is ready to be reviewed. We have a CI pipeline running different checks for every PR. It makes little sense to review a pull request that hasn't passed all test yet since there might be failures and further changes to address them.

  3. There's no way for PR author to know when their pull request is ready to be merged

How does this process work in your team and are you happy with it? What's the most annoying part of reviewing others pull requests?

Regards!

Hassle-free blogging platform that developers and teams love.
  • Docs by Hashnode
    New
  • Blogs
  • AI Markdown Editor
  • GraphQL APIs
  • Open source Starter-kit

© Hashnode 2024 — LinearBytes Inc.

Privacy PolicyTermsCode of Conduct