Stacking PRs
How this technique levels up engineers
Programmer's log. Epoch time 1670210685. We are currently in Boston visiting the in-laws for an early Christmas celebration. We drove from San Francisco to Florida to visit my family for Thanksgiving and last week made the drive up the East Coast. Overall, the driving hasn't been too bad, with the exception of almost losing our minds with stress navigating the NJ Turnpike. While it's been nice to be able to work remotely during this road trip (definitely a bucket list item to drive coast-to-coast!), it's been more stressful than fun making daily driving progress while also working and trying to not default to eating Burger King every day in these small American towns. Being a digital nomad is probably not for me...
Hi all,
Happy December! ❄️ This is a digest for my blog, Simulated Annealing. Reach out with thoughts on Twitter @vivqu or by replying to this email.
Recent posts:
Stacking PRs
How this technique levels up engineers
University computer science curriculums frequently don’t teach practical industry skills that are required to succeed in the workplace. Students are given toy assignments that demonstrate high-level concepts but are rarely required to produce an end-to-end implementation with the goal of real users interacting with the system. Even in internships, projects are usually limited to small, well-scoped projects that can be tidily wrapped up in 3-4 months. This means that most of the coding projects that new grads have completed by the start of their first industry role have been isolated to just one person, or have had only minimal collaboration with others. Basic git commands are usually one of the major gaps that new grads have to learn on the job.
Becoming proficient in version control and change management is a necessary part of any software engineer’s job. However, I think that basic proficiency alone is not sufficient to be truly effective when working on complex production-ready software with a team of engineers. Stacking pull requests (PRs) is a key skill that should be learned early in a junior engineer’s career.
Stacking PRs is an advanced git technique that allows an engineer to break down one large change into a series of dependent changes that can be turned into smaller pull requests and reviewed separately.
Imagine a new full-stack feature that requires frontend and backend changes. An engineer might work on both parts simultaneously to implement and test the full functionality. A basic pull request would contain all of these changes, potentially hundreds of lines of code (LOC):main-branch
|
------ all-my-changes (PR #1, 500 LOC)
Instead, the engineer could separate the changes into two separate branches, one for frontend changes and one for backend changes. The frontend branch would need to be stacked on top of the backend changes since it uses new APIs.main-branch
|
------ backend-changes (PR #1, 300 LOC)
| ------ frontend-changes (PR #2, 200 LOC)
This is a better state since each pull request is focused on one specific sub-area of the larger functionality. Each pull request also contains fewer lines of code to review. Stacking PRs can also be done in the middle of feature development, rather than at the end, to enable an engineer to continue to develop additional changes while waiting for a review on the first set of changes.
Timothy Andrew has a detailed write-up of the stacked PR workflow and tools to make the workflow easier. Stacking PRs can be quite cognitively complex because it requires dexterity with branching, cherry-picking, and rebasing commits. Engineers need to be able to thoughtfully decompose their work into comprehensible chunks, which may be challenging if there are many interdependent changes. There is also some practice required to learn how to update a base branch to address comments and merge the pull requests in the appropriate order.
(Note: GitHub finally added in pull request retargeting in 2020 to make managing multiple feature branches easier, demonstrating how critical the stacked PRs workflow is to advanced software development practitioners. Phabricator (RIP) was an arguably better platform for this workflow due to stacked diffs, a variant on the same idea of chunking up a large body of engineering work. Perhaps it’s unsurprising that I’m a huge fan of stacked pull requests given I used Phabricator at my first job! It’s also why I like squashing my commits when I merge in approved pull requests.)
...
(Click here to read more)
Hit me up with your thoughts @vivqu. See you later, alligator! 🐊