My biggest Pull Request
Tags: development
Published: 2020-08-02 09:07:12

---
title: My biggest Pull Request
published: true
description: Lessons learned from my biggest Pull Request. What to do when the Pull Request is too big?!
tags: 
  - development
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/gkxkr6tfmfpuccwfmmo9.jpg
---

> Originally posted on [strdr4605.github.io](https://strdr4605.github.io/my-biggest-pull-request)

## 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

![bitbucket-warn](https://dev-to-uploads.s3.amazonaws.com/i/l9myjjrk7vfsnt6ykfp7.png)

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(-)`** <br/>
Beside 420 files maybe 20-40 files were added and removed in between. <br/>
- Changes from **140 days** <br/>
- **163 commits** <br/>
- **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 <br/>
  and let the team review each commit separately.
- Don’t squash everything. <br/>
Let styling/formatting commits be separate from implementation commits.
- Create `temporary-master` branches <br/>
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. <br/>
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.