My biggest Pull Request

Originally posted on strdr4605.github.io

The story

I was working on a white-label mobile application in active development.
(If you plan to develop a white-label mobile app, JUST DON'T!!! 😅 But this is a story for another post.)
I implemented a BIG FEATURE that was very tightly coupled with back-end implementation.

The PRs were created, reviewed, and approved by front-end and back-end teams.
Everything was tested, some small bugs were found, I fixed them and was ready for merging to master branch.
But some severe bugs and priority features had to be done,
so the back-end developer had to switch working on them and the back-end implementation was not shipped in production.

I didn't want to merge my commits in master branch,
as the implementation in back-end may be changed after addition of other requirements
and decided to wait until the back-end developer will be free and ready to merge his implementations.

I thought that the feature will be shipped the week after.

Meanwhile, I started working on the next feature that was based on the BIG FEATURE.
When I finished I didn't create a new PR in master branch as the feature2 branch included changes from feature10.
After a week I asked the back-end developer about the status with BIG FEATURE shipment to production,
but he was busy with other tasks and as the app was in active development I continued developing on top of big-feature branch.

I was working alone in that repo and the front-end devs were helping me only with pair programming or opinions on feature implementations.
No one needed my changes and I took the easy path of just working on features/bugs and creating builds directly for testers and onboarding clients.

Time has passed, the back-end developer forgot about the BIG FEATURE.
I was working on features and bug fixes.
feature5, feature10, feature13, bugfix12, refactor2 branches were all created on top of big-feature branch.

One day I understood that the PR in master branch will be an ENORMOUS lesson for me and the team.
Another developer joined the project so I created a new dev branch from feature16 and for the last 2 weeks, we created and reviewed PRs in dev branch.

Finally after 140 days from the beginning of BIG FEATURE the back-end implementation was merged and shipped to prod.

And I was ready for my biggest Pull Request (so far).

The Pull Request

It was so big that BitBucket couldn't display it. The only way to review it was by checking each commit separately or maybe using a desktop git client.
Additional complexity added mobile-specific files that were generated by XCode and Android Studio.

Stats:

• 420 files changed, 25739 insertions(+), 19429 deletions(-) Beside 420 files maybe 20-40 files were added and removed in between.
• Changes from 140 days
• 163 commits
• 36 intermediary branches

In the end, I received 3 approves and only one comment.

"Omg" - Tech Lead (implemented the back-end for BIG FEATURE)

Lessons learned

• Make small PRs.
• One feature | bug-fix | refactor per PR.
• If the PRs includes several features squash commits to have one commit per feature and let the team review each commit separately.
• Don’t squash everything. Let styling/formatting commits be separate from implementation commits.
• Create temporary-master branches If features relay on other features that are not in master. Or you are working on a BIG FEATURE, divide BIG FEATURE in big-feature-phase-1, big-feature-phase-2. Create temporary branches like dev and make PRs in dev.
• Create "Fix PR comments" commits and then squash them. If PR is big and you have several comments, fix them in a separate commit and let reviewers check only it. After approval squash "Fix PR comments" commit in previous feature commit.
• Be kind to your reviewers.
• Make small PRs.