I’ve struggled a long time with what has become common notation – the “PR”. When I first heard it used, I learned that it was a term used in GitHub but I could never remember what it meant – didn’t match my mental model, so I’d have to look it up again and again.
It is an event that takes place in software development when a contributor/developer is ready to begin the process of merging new code changes with the main project repository. The name “pull request” came from the idea that someone is requesting the project to pull changes from their feature branch.
It’s also referred to as a merge request which makes way more sense to me since that is what is really happening, so now I mentally change PR to merge request and I’m good.
However, I was reading The 2022 State of Testing in DevOps Report by mabl, and got confused all over again when I saw these following charts.
So, when did Pull Requests (request to merge) become a stage in a SDLC? Especially as a stage for executing functional tests. A PR (when accepted) will trigger a build (Continuous Integration) which will run some of the tests – perhaps all. It’s not the PR itself, right?
And how are bugs found in a PR? This chart makes no sense to me at all. I possibly could see bugs being found during the merge with the main branch, but the request itself – no. JUST no.
I think to myself, if I’m confused, what happens to the rest of the world. The terms we use and how we use them, are important.
As I was writing this blog post, I noticed a twitter conversation about PRs started by Matt Wynne. I won’t reiterate the conversation, but it sounds like I’m not the only person with some issues with how the term is being used.
Check out this conversation https://twitter.com/mattwynne/status/1641540417773801478 if you want to see more differing opinions on the subject.