999 Merged PRs. Here’s what I have learnt so far.

Mister Weru — Tue, 24 Mar 2026 08:47:36 +0000

So a little background information. My name is Dennis Weru, a software engineer at Workpay, one of the most exciting startups in Africa. I am frontend heavy and most of my work has been on UI of the performance management module. We built it on Next Js utilising the static exports feature. This enables us to achieve very fast load times and very tiny pages as you can see below.

This project was built from scratch starting sometime in April 2023 and multiple developers have contributed to it to date. Starting afresh gave us a lot of flexibility in trying out tools and methodologies that could possibly be integrated into the core Workpay HR and payroll codebase which is built separately.
The performance management codebase has reached a significant milestone which is 999 merged PRs.

These are all PRs targeted to the three main branches that we use, I explain this in the next section. These are a few things that I have learnt working on the codebase for close to two years now.
These are a few things that I have learnt working on the codebase for close to two years now.

Multiple environments, Multiple headaches.

At Workpay, we have three environments; develop, staging and production.
Develop is the tinker branch and it offers the engineers a place to test their work independent of their laptops. Any engineer can merge to develop anytime once they test their work. This gives us flexibility to test new modules and packages and see how they play with the rest of the codebase.
Staging branch is the product branch and it allows the product team to demo new features to stakeholders and other interested parties. Staging branch is a replica of the production branch with a few additional features. It only contains stable changes that have been tested by the Quality Assurance team and developers can only merge to this branch once QA clears the PRs.
Production branch contains the changes that are available to our active users. PRs are only merged to production once code reviews are complete and the QA approves them for production.
Herein lies the headache, how do we ensure the branches don't diverge too much leading to endless merge conflicts?

Approach one

We tried a couple of approaches in this regard. The first approach was as
follows.

Feature branches were always created from develop and the PRs pointed to the same branch.
After the feature development is complete, the feature branch is tested by the engineer and merged to develop.
Once the develop branch is tested and cleared by QA, a PR is created and the entire develop branch is merged to staging.
Another round of tests is done in Staging and after the feature is cleared, a PR is created and the entire staging branch is merged into production.
Bug fix branches were created from the respective branch that the bug was found and the PRs pointed to the same branch.

This approach allowed us to move fast since only one PR was ever created for each feature. We had a consistent weekly release cycle which ensured that the develop branch would be merged to staging once a week, the same for the staging branch to production.
Like Murphy's law dictates, everything that could go wrong did. Incomplete features started finding themselves in staging due to a myriad of factors including edge cases or sloppy testing. This lead to work getting stuck in staging for longer than the one week release period as bugs were resolved.
The worst case was a major feature that was merged into staging before a couple or edge cases had been looked at. Fixing all the edge cases took close to two months. During the two months, all the other fixes and small features that were to go to production could not move before the major feature was shipped. Some branches went stale, it began to stink, you can imagine how this looked to the executives at the company.

Approach Two

Something had to be done. We worked on a new development approach;
Feature branches are always created from production and the PRs always point to production.
Once the feature is complete, the developer alerts the QA personnel who in turn tests the work from the feature branch locally.
The developer then creates an additional two PRs from the feature branch. One to staging and another to develop.
Before merging the develop and staging PRs, you have to rebase them with their respective branches. This will ensure that you resolve any conflicts that may come up.
The developer merges the develop PR.
QA tests the work in the develop environment and clears it for staging.
Developer merges the staging PR and QA does the final round of tests.
The feature branch is merged to production.
Bug fix branches were created from the respective environment they were reported and target the same branches.

This new approach showed a few improvements over the previous model. Since all branches were created from production, we could ensure that we're always starting from stable code before adding features or improvements.
It also allowed us to have small PRs that could quickly go through the development cycle without halting other ongoing tasks. We were able to ship stuff more frequently since we did not have to wait for big releases to introduce features. Bugs found on an individual feature branch did not halt the development of other features.
Then came the fuckening. Having to maintain three separate PRs for the same feature meant more work for the developers who had to constantly rebase the feature branches with the respective target branch.
Work was rarely merged to production in the same order as develop and staging. This in turn meant that any branch created from production will always have conflicts with staging and develop due to the different commit histories.
The more time went by, the harder and more complex the rebases became. It got to a point that for all branches going to staging or develop, the developer had to resolve conflicts for more than 20 commits. Getting this right every time was hard and some bugs started creeping up simply due to the rebasing process. It was also very time consuming.

Approach Three

It was time to switch things up. The main issue we were facing was due to all branches originating from production. We made a decision to make use of transition branches which were always created from the respective target branches. The flow went like this;
Feature/Chore branches are always created from production.
Once the code is complete, the developer creates a PR to production and alerts the QA personnel who in turn tests the work from the feature branch either locally or using Cloudflare preview links.
The developer then creates an additional two PRs. One from develop and one from staging using a similar name to the production branch. All we do is add '-develop' or '-staging' at the end.
Before merging the develop and staging PRs, you have to rebase them with their respective branches. This will ensure that you resolve any conflicts that may come up.
The developer merges the develop PR.
QA tests the work in the develop environment and clears it for staging.
Developer merges the staging PR and QA does the final round of tests.
The feature branch is merged to production.
Bug fix branches were created from the respective environment they were reported and target the same branches.

We finally settled on Approach three since it allowed us a couple of advantages.
First, work could be tested using Cloudflare preview links from the PR. This freed up time required to merge the work to the develop environments.
Second, the process was also less messy incase some of the work had issues. Previously, we had to revert the branch from develop, but using preview links we could test the changes without merging work
Third, the cloudflare CI added an additional layer of confidence since the pipeline has to build the work and run linter checks. For work that does not pass the checks, it is never merged to the corresponding branch.

Cherry-Picking for the win
Any work eventually has to have three PRs. When creating the corresponding staging and develop PRs for any given PR, the process initially was very messy. The commands I was using were git rebase and git merge to get the changes I needed. However any experienced Engineer knows the headaches of constantly resolving merge conflicts.
I stumbled on the git cherry-pick command when talking with a colleague about the issue I was having and he told me put me on. I honestly never felt so much relief. I could now checkout to a new branch from develop and cherry pick the commits from the production PR I had created. Seamless and rarely results in conflicts.
Now it is a daily part of my SDLC.

Code reviews are necessary
When we began the project, there were only two of us on Frontend. However as the project progressed, more engineers worked on the codebase. It became prudent for us to think about the standards we wanted to enforce within the codebase. Things that were obvious to the two of us initially suddenly was not so obvious for new engineers.
There were cases of duplication of components and logic for things that were already built. Unacceptable of course.
Code reviews for all work became mandatory and this allowed us to catch anti patterns early and ask for changes early in the development lifecycle.

Cloudflare Preview Links for the win
Cloudflare preview links for all PRs that are pointed to production, develop and staging branches were set up almost a few months into the project. It felt like a brave new world. Fixes and features could be tested directly from preview links without needing to merge to the develop branch.
Eventually the develop branch lost its relevance. We mostly use it now to test out new things but there is no pressure to keep it up to date with Production.

Final Thoughts
999 PRs may look like just a number, what you don't see is the sleepless nights, rushed deadlines, missed deadlines, painful reverts and digging though endless merge conflicts.
Building out the Performance management module has been a roller coaster. It has been a journey seeing the codebase you built age and having to deal with dependency issues. It opened my eyes to the real world of building and maintaining enterprise software and I will forever be grateful for the lessons learnt.

DEV Community: Mister Weru

999 Merged PRs. Here’s what I have learnt so far.