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 an entire team is working on the project? If everyone merges their changes directly into the main branch main, chaos will start very soon: someone might accidentally add buggy code, break the build, or delete an important part of a colleague’s work.

To avoid this, team 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.

Pull Request is an official request: "Please pull my changes from my branch and merge them into the main branch." But it is not just a request—it is an entire space for discussion, review, and improving the code before it gets into main.

2. The standard Pull Request workflow

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

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

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

Step 1. Create a branch for the new task.

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

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

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

This is the key step! A Pull Request is created from 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 the IDE, find the tool window Pull Requests. Open it and click 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 convenient interface for you. Your job is to fill it out properly. Let’s review the main fields:

1. Title: the IDE often inserts the branch name or the text of your last commit here. Make sure the title is short, clear, and reflects the essence of the changes.
2. Description: here you explain to your teammates in detail what exactly you did and why.
3. Reviewers: here you select one or more teammates who should review your code. In a learning project, we will skip this step, but in real work it is mandatory.
4. Assignees: usually you specify yourself here. This means you are the author and the primary person responsible for this task and for applying changes after review.

After all fields are filled in, confidently click Create Pull Request.

4. Code review: checking and discussion

After creating the PR, the most important stage begins—code review. Your teammates can open your PR, view all changes, and leave comments.

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

What if you are asked to make changes?

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

5. Wrapping up: merge and delete the branch

When all feedback is addressed and the team approves your changes (you get an "approve"), the Pull Request can be merged. Usually this is done by a senior developer or by you yourself if you have such permissions in the repository.

Step 1. Merge

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

Step 2. Delete the branch.

After merging, your `feature` branch is no longer needed, and you should delete it to avoid cluttering the repository. GitHub will suggest doing this by showing the Delete branch button.

Do not forget to also delete the local copy of the branch in your IDE and run 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 only the right message, but also the right content. To keep your change history clean, useful, and professional, follow three simple rules.

Rule 1: write clear messages using a standard

Your commits are messages you send to your team and to your future self. A history full of messages like "fix" or "update" is absolutely useless. The most popular standard is called Conventional Commits. It suggests 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 documentation changes.
• style: — for formatting changes that do not affect code logic.
• refactor: — for code changes that add no new functionality and fix no bugs.
• test: — for adding or fixing tests.
• chore: — for routine tasks not related to code (dependency updates, 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)

Do not try to fit a bug fix, a new feature, and a refactor of old code into a single commit. Such a commit is very hard to review, and it is almost impossible to revert cleanly if something goes wrong.

Each 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 work you changed too much at once in a single file, IntelliJ IDEA lets you commit not the entire file! In the Commit window, you can expand the file and check only those code fragments (chunks) that belong to a specific logical task.

Rule 3: a commit must not break the project

Each commit in the main branch should leave the project in a working state. Before creating it, you should at least make sure the code compiles. But how can you be sure you did not accidentally break something in another part of the system? Relying only on manual testing is risky.

This is where automation helps. In this course, we will not set up automated processes, but you should know how this 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 DevOps) configure 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 runs your workflow on a remote server.
2. It automatically "builds" the project and runs all the tests you wrote.
3. If all tests pass successfully, a green checkmark appears next to your commit on GitHub. This signals to the whole team that your changes are safe.
4. If at least one test fails, you will see a red X. Merging such a PR into the main branch is strictly forbidden 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
        

You can set up notifications. If tests fail, GitHub Actions can send an email to you or to 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.