Phase 1: Programming & Fundamentals

Pull request workflows & code reviews

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you and your friends are building a super-duper giant Lego castle together. It's a huge project, so you can't all just pile in and start adding bricks everywhere at once, right? That would be chaos! Someone might accidentally knock over a wall, or add a tower that doesn't quite fit the overall plan. To keep things organized and make sure the castle turns out amazing, you have a special way of working.

Instead of building directly onto the main, already-built part of the castle, each of you gets your own separate little section of the table, or your own small box of special bricks. Let's say your job is to build a cool new drawbridge. You work on your drawbridge by yourself in your section, making sure each brick you add is firm. Once you've finished building your perfect drawbridge, you don't just go and snap it onto the main castle.

That's where a "Pull Request" comes in. It's like proudly calling out to your friends, "Hey everyone, I've finished building my awesome new drawbridge! Can you all take a look at it before I try to connect it to the main castle?" This is your way of asking them to pull your finished drawbridge from your separate area and bring it over to the main castle. It's a crucial step because it makes sure no new part gets added without everyone checking it carefully and agreeing that it's a good idea. This helps prevent mistakes and makes sure your castle stays strong and looks great!

You’d also explain what your drawbridge does and how you built it. Then, you ask your friends (your teammates) to come over and be the "reviewers". This is where code reviews start. They'll look at your drawbridge and give you feedback, like suggesting a stronger brick or noticing something doesn't quite line up. This way, everyone works together to make sure every single new piece added to the castle is the best it can be. So, when you're building real software with other people, this is how you ensure all the different parts fit together perfectly and work without problems.

When you're building software as part of a team, you'll rarely commit directly to the main codebase. Instead, you'll work on your own separate "feature branch" for specific tasks. A Pull Request (PR) is your formal way of telling your team, "Hey, I've finished implementing this new feature or fix on my branch, and I'd like you to review my changes before they become part of the main project." Think of a PR as a request to pull your changes from your temporary branch into the target branch (like main or develop). It’s a crucial step that ensures no code gets into the main project without scrutiny and team consensus, fostering collaboration and preventing errors.

The typical workflow looks like this: you start by creating a new branch for your task, make your code changes, commit them regularly, and then push your branch to the shared remote repository. Once pushed, you'll go to your Git hosting platform (like GitHub, GitLab, or Bitbucket) and open a Pull Request. In the PR description, you'll explain what you did, why you did it, and any relevant context or linked issues. Then, you'll assign teammates as "reviewers" who will examine your work.

This is where code reviews come in. Your assigned reviewers will carefully examine your code changes within the PR interface. They'll look for potential bugs, suggest improvements for clarity or performance, ensure coding standards are met, and generally help elevate the quality of the codebase. It's a collaborative process for knowledge sharing and catching issues early, not a personal critique. Reviewers leave comments directly on specific lines of code or provide general feedback. Once all concerns are addressed and the code meets the team's standards, reviewers approve the PR, allowing it to be merged into the target branch, effectively making your changes live.

Key Takeaways

  • Pull Requests (PRs) are formal proposals to merge your code changes into a main branch.
  • Code reviews are essential for quality assurance, consistency, and knowledge sharing among team members.
  • Always work on a dedicated feature branch and push it to the remote before opening a PR.
  • Provide clear descriptions in your PRs and be open to feedback during reviews.
  • Code is only merged into core branches after it has been approved by reviewers.

Code Example

bash
# 1. Create and switch to a new feature branch
git checkout -b feature/add-user-profile

# 2. Make your code changes (e.g., add new files, modify existing ones)
#    ...

# 3. Stage and commit your changes
git add .
git commit -m "feat: Implement basic user profile endpoint and data model"

# 4. Push your local branch to the remote repository
git push origin feature/add-user-profile

# 5. Now, go to your Git hosting platform (GitHub/GitLab/Bitbucket) 
#    to create a new Pull Request from 'feature/add-user-profile' 
#    into your target branch (e.g., 'main' or 'develop').

How this code works

This script demonstrates the essential Git commands for developing a new feature and proposing it for integration using a pull request workflow. It starts by isolating new work from the main codebase. The git checkout -b feature/add-user-profile command creates a brand-new branch specifically for the 'add-user-profile' feature and immediately switches the developer's working directory to it. After making necessary code changes, git add . stages all modifications, preparing them for a snapshot. These staged changes are then saved permanently to the feature branch's history with git commit -m "feat: Implement basic user profile endpoint and data model", including a descriptive message.

Once local development is complete and committed, the git push origin feature/add-user-profile command uploads this entire new branch, along with its specific commits, to the remote Git repository. A subtle but crucial point here is explicitly naming the feature branch (feature/add-user-profile) in the push command; this ensures only the new, isolated work is sent to the remote, avoiding accidental pushes to a main development branch. Finally, with the feature branch available remotely, the pull request process is initiated on a Git hosting platform (like GitHub or GitLab), requesting that the feature/add-user-profile branch be merged into the project's target branch.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control.

Back to Backend Developer Roadmap