Nadia Zubko's blog
The Beauty of Pull Requests

Photo by Alice Yamamura on Unsplash

The Beauty of Pull Requests

Nadia Zubko's photo
Nadia Zubko
·

5 min read

Table of contents

Intro and a bit of Backstory

At the start of my web development journey, I was taught to always use pull requests (PRs), though I never fully understood the reasoning behind it since pushing to main seemed way quicker.

I'm grateful for my experience at The Collab Lab, where mentors shared an excellent pull request template structure that I've saved in my own GitHub repository for future use: https://raw.githubusercontent.com/N-Zubko/PR-template/main/PR_template.md. Their git lecture was also invaluable - they introduced me to 'Dangit, Git!' https://dangitgit.com/en, a resource that has become my go-to guide for navigating git commands.

Honestly I still did not fully appreciate the importance of the PR flow in my personal and study projects. However, I grew to see that the PR workflow really proves its worth while working on larger scale collaborative projects where multiple developers contribute and code quality and app stability are crucial.

It’s year 2024, almost 2025, and some will still argue against using pull requests and feature branches, preferring a direct commit-to-main workflow. Let’s explore the advantages and address the criticism.

The Power of Pull Requests in Code Reviews

What is a pull request? A pull request aka PR is a formal request to merge code changes into a main branch. It typically includes code changes, context for those changes, and the opportunity for peers to review and discuss them before they’re merged. Here's why I've come to love PRs for code reviews:

  1. Code Quality

    • 🤩 By requiring code reviews, PRs introduce an extra layer of quality control. Reviewers can suggest improvements, ensure coding standards are maintained, catch bugs. At the same time, they can't simply wave away the need for review, since branch protection rules prevent merging into main without proper PR approval.

  2. Collaboration and Knowledge Sharing (this is my favourite)

    • 🤩 Code reviews through PRs aren't just about catching errors. They’re also opportunities for developers to share knowledge and learn from one another. A well-explained PR can introduce new design patterns, or better coding techniques. You can add links and references to your comment which is way more useful than any verbal review.

  3. Asynchronous Feedback

    • 🤩 Unlike quick chats in messengers or a verbal comment that you might forget, PR discussions create a perfect space for thoughtful feedback that you can always come back to.

  4. Traceability

    • 🤩 PR comments stay with the code. When future developers (including future you) wonder "why did we do it this way?", the PR history tells the whole story.

  5. Onboarding

    • 🤩 New developers can review old PRs to get up to speed with code standards and practices.

Why Written Comments in PRs Are Better than Verbal Feedback

While verbal communication is quick it is prone to misunderstandings. From this point of view, PR comments offer several advantages:

  • 🤩 Persistence because written comments are permanent and can be referenced later, providing clarity on the thought process behind changes;

  • 🤩 Clarity since reviewers have a chance to write detailed, structured feedback, include code snippets and links to documentation if needed;

  • 🤩 Accessibility for team members working in different time zones or with varying schedules, as well as those who struggle with understanding verbal comments due to a language barrier;

  • 🤩 Learning Resources because team members can browse old PRs to understand code evolution and decisions.

Feature Branches for Stability and Safety in Development

Pull requests come hand-in-hand with feature branches. Let’s define what a feature branch is.

A feature branch is a separate branch where developers work on a specific feature before merging it into the main branch. Feature branches when combined with pull requests and correct use of git commands improve stability:

  1. Isolated Development:

    • 🤩 Feature branches keep new changes isolated, preventing incomplete or buggy features from affecting the main branch and whole web app.

  2. Safe Integration:

    • 🤩 Only after a feature branch passes code review and tests is it merged into the main branch. This ensures that the main branch remains stable.

    • 🤩 It is important to keep your feature branch up-to-date by regularly merging the main into the feature branch to reduce conflicts and ensue compatibility.

  3. Parallel Workflows:

    • 🤩 Multiple developers can work on different features simultaneously without stepping on each other’s feet.

  4. Rollback Safety:

    • 🤩 If something goes wrong, it’s easier to revert a single PR than to untangle a series of direct commits or pushing commits reverting previous changes.

Addressing the Criticism

Some developers prefer committing directly to the main branch, believing it speeds up development. Their reasons might include:

🚧 “Pull requests slow down development"

🤩 While PRs introduce a review step that requires dedicated work time, in the long run this step ensures code quality and stability. Bugs caught during a PR save much more time than fixing issues after deployment.

🚧 “Feature branches create merge conflicts and overhead"

🤩 Conflicts can happen, but they’re manageable with regular integration, e.g. merging from the main regularly. Conflicts will still occur without feature branches, but they are harder to isolate and resolve.

🚧 “Direct commits are simpler/quicker"

🤩 Simplicity in process shouldn’t come at the cost of code quality or application stability. PRs and feature branches provide structure that scales well with growing teams and projects.Simple and quick commits cause a lack of collaboration and potential quality issues go unnoticed.

Conclusion

This article is a message from the depth of my heart. Pull requests and feature branches are more than just "process overhead." They’re essential tools for improving code quality, fostering collaboration, and maintaining a stable development pipeline. While committing directly to main may seem faster in the short term, the long-term benefits of PRs and feature branches far outweigh the initial learning curve for those new to PRs. With proper time management thanks to the PR practices, teams can:

  • Write better, more stable and safer code

  • Share knowledge more effectively

Pull Requests