The Magic of Pull Requests

1. From merging to proposing: why do we need Pull Requests?

In the previous lecture, we learned how to merge branches on our local computer. This works great when you are working alone. But what if a whole team is working on the project? If everyone merges their changes directly into the main main branch, chaos will soon ensue: someone might accidentally add buggy code, break the build, or delete an important part of a colleague's work.

To avoid this, collaborative development uses a different approach. Instead of merging changes immediately, you create a merge proposal. This proposal is called a Pull Request (PR for short) or, on some platforms, a Merge Request.

A Pull Request is an official request: "Please pull my changes from my branch and merge them into the main branch". But it's not just a request; it's a whole platform for discussing, reviewing, and improving code before it makes its way into main.

2. Standard Pull Request workflow

Let's go step by step through what a typical workflow looks like when creating a new feature.

Before creating a branch for a new task, make sure you have pushed all your finished commits and updated the main main branch using Update Project.

Otherwise, all your "forgotten" local commits from main will accidentally end up in the new Pull Request, creating confusion for your colleagues.

Step 1. Create a branch for the new task.

As before, any new work starts with creating a separate branch. Let's say we want to add a file with contribution guidelines to our project. We will create the branch feature/add-contribution-guide.

Step 2. Make changes and push your branch to GitHub.

In the new branch, create a CONTRIBUTING.md file (click Add after creating it) and write a message to other developers in it. After that, perform a Commit and Push with a clear message, for example: docs: Add contribution guide.

This is a key step! A Pull Request is created based on a branch that already exists on the remote server. Therefore, before creating a PR, you must push your new branch to GitHub.

3. Creating a Pull Request from IntelliJ IDEA

Now that your branch is on GitHub, you can create a Pull Request.

Step 1. Open the Pull Requests tab.

On the left sidebar of your IDE, find the Pull Requests tool window. Open it and click on the + icon (or the Create Pull Request button) to create a new PR.

Step 2. Fill in the PR details.

The IDE will automatically open a user-friendly interface for you. Your task is to fill it out properly. Let's look at the main fields:

1. Title: The IDE often inserts the branch name or the text of your last commit here. Ensure the title is concise, clear, and reflects the essence of the changes.
2. Description: Here you explain in detail to your colleagues exactly what you did and why.
3. Reviewers: Here you select one or more colleagues who should review your code. We will skip this step in the educational project, but it is mandatory in real work.
4. Assignees: Usually, you specify yourself here. This means you are the author and the primary person responsible for this task and for making corrections after the review.

Once all the fields are filled out, go ahead and click Create Pull Request.

4. Code Review: checking and discussing

After creating the PR, the most important stage begins — Code Review. Your colleagues can open your PR, view all the changes, and leave comments.

You can see all the discussions right in your IDE in the Pull Requests tab. If someone leaves a comment on a line of code, you will receive a notification and can reply to it without switching to the browser.

What to do if you are asked to make changes?

It's very simple! You don't need to create a new PR. Just make the necessary changes to the code in your current branch, make a new commit, and push it. The Pull Request on GitHub will automatically update, adding your new commits to the existing discussion.

5. Finishing up: merging and deleting the branch

When all comments have been addressed and the team approves your changes (you get an "approval"), the Pull Request can be merged. This is usually done by a senior developer or by yourself if you have such rights in the repository.

Step 1. Merge

Merging most often occurs on the GitHub website or directly from the Pull Requests window in your IDE. A large green Merge pull request button will appear under your PR on GitHub. After clicking it, your code will become part of the main main branch.

Step 2. Deleting the branch.

After merging, your `feature` branch is no longer needed, and it should be deleted so as not to clutter the repository. GitHub will offer to do this by displaying a Delete branch button.

Don't forget to also delete your local copy of the branch in your IDE and do an Update Project on the main branch to pull the merge results to your computer.

6. Three rules of a good commit

A good commit is not just about a proper message, but also proper content. To keep your history of changes clean, useful, and professional, stick to three simple rules.

Rule 1: Write clear messages following a standard

Your commits are messages you send to your team and your future self. A history full of "fix" or "update" messages is absolutely useless. The most popular standard is called Conventional Commits. It proposes the following structure:

<type>: <short description>

Type is a short word describing the category of your changes:

• feat: (feature) — for new functionality.
• fix: — for bug fixes.
• docs: — for changes to the documentation.
• style: — for formatting changes that do not affect code logic.
• refactor: — for code changes that neither add new functionality nor fix bugs.
• test: — for adding or fixing tests.
• chore: — for routine tasks not related to the code (updating dependencies, build configuration).

Examples:

• Bad: fixed bug
• Good: fix: Correct user login validation

• Bad: readme
• Good: docs: Update installation instructions

Rule 2: One commit — one logical change (Atomicity)

Don't try to fit a bug fix, adding a new feature, and refactoring old code into a single commit. Such a commit is very difficult to check during a review, and almost impossible to revert painlessly if something goes wrong.

Every commit should solve only one specific task.

• Bad: one commit with the message "Update user page" that adds an avatar field, fixes a bug in name validation, and changes button colors.
• Good: three separate commits:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

If you realize that in the heat of the moment you have changed too many things in one file, IntelliJ IDEA allows you to commit just parts of the file! In the Commit window, you can expand the file and check only the boxes next to those code chunks that relate to a specific logical task.

Rule 3: A commit must not break the project

Every commit in the main branch should leave the project in a working state. Before creating it, you should at least make sure that the code compiles (e.g., by running go build). But how can you be sure you haven't accidentally broken something in another part of the system? Relying solely on manual testing is risky.

This is where automation comes to the rescue. In this course, we won't be setting up automated processes, but you should know how it works in real projects. Modern teams use Continuous Integration (CI) systems, such as GitHub Actions.

How does it work?

You write code and tests for it. Then you or a DevOps engineer set up a special workflow directly on GitHub. Now, as soon as you push to your Pull Request, magic happens:

1. GitHub Actions sees this event and triggers your workflow on a remote server.
2. It automatically "builds" the project and runs all the tests you've written (for example, executing the go test command).
3. If all tests pass successfully, a green checkmark appears next to your commit on GitHub. This is a signal to the whole team that your changes are safe.
4. If even one test fails, you will see a red cross. Merging such a PR into the main branch is strictly prohibited until the errors are fixed.

            graph LR
            subgraph GitHub
            A[Developer] -- "push" --> B(Repository)
            B -- "Event: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Run" --> D[Run_tests]
            D --> E[Success]
            D --> F[Failure]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Developer]
            G --> I[Team]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

Notifications can be configured. If tests fail, GitHub Actions can send an email to you or the whole team. This approach creates a culture where tests are not just a formality but an integral part of development, and everyone is responsible for the quality of their code.