The magic of pull requests

1. From merge to proposal: why you need Pull Requests?

In the previous lecture, we learned how to merge branches on your local computer. That works great when you work 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 soon: someone may accidentally add buggy code, break the build, or delete an important part of a colleague’s work.

To avoid this, team development follows a different approach. Instead of merging changes right away, 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’s not just a request — it’s a full space for discussion, review, and improvement of the code before it lands in main.

2. Standard pull request workflow

Let’s go step by step through a typical workflow for creating new functionality.

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

Otherwise, all your “forgotten” local commits from main will 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 contribution rules to our project. 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, click Add) and write a message to other developers. After that, do 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 need to 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 in the IDE, there is the Pull Requests tab. Open it and click the + icon to create a new PR.

Step 2. Fill in the PR details.

The IDE will automatically open a convenient interface for creating a pull request. Your task is to fill it out properly. Let’s go over the main fields:

1. Title: The IDE often substitutes the branch name here, but that’s a bad practice. The title should be short, clear, and reflect the essence of the changes — like a good commit message.
2. Description: here you explain what you did and why.
3. Reviewers: here you choose one or more teammates who should review your code. In the training project we’ll skip this step, but in real work it’s mandatory.
4. Assignees: usually you specify yourself here. This means you are the author and the person primarily responsible for this task and for making changes after the review.

After all fields are filled in, go ahead and click Create Pull Request.

4. Code review: verification and discussion

After the PR is created, the most important stage begins — code review. Your teammates can open your PR, look through all the changes, and leave comments.

You can see all the discussions right in the IDE in the Pull Requests tab. If someone leaves a comment, you will receive a notification.

What if you’re asked to make changes?

Very simple! You don’t need to create a new PR. Just make the necessary changes in the code in the same branch, create a new commit, and push it. The pull request on GitHub will update automatically, adding your new commits.

5. Finishing up: merge and delete the branch

When all comments are addressed and the team approves your changes, the pull request can be merged. Usually this is done by a senior developer or by you if you have the permissions.

Step 1. Merge

The merge most often happens on the GitHub site. There will be a big green button Merge pull request under your PR. After clicking it, your code becomes part of the main branch main.

Step 2. Delete the branch.

After the merge, your ‘feature’ branch is no longer needed, and it should be deleted so as not to clutter the repository. GitHub will suggest this itself, showing the Delete branch button.

Don’t forget to also delete the local copy of the branch in your IDE to keep things tidy. You can do this through the same branch management menu.

6. Three rules for commits

A good commit is not only a proper message but also proper content. To keep your change history clean, useful, and professional, follow three simple rules.

Rule 1: write clear messages following 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 summary>

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

• feat: (feature) — for new functionality.
• fix: — for a bug fix.
• docs: — for documentation changes.
• style: — for formatting tweaks that don’t affect code logic.
• refactor: — for code changes that don’t add new features and don’t 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 squeeze a bug fix, the addition of a new feature, and refactoring of old code into a single commit. Such a commit is very hard to review and almost impossible to revert safely if something goes wrong.

Each commit should solve only one specific task.

• Bad: a single 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

Small, focused commits are much easier to understand and manage.

Rule 3: a commit must not break the project

Every commit in the main branch must leave the project in a working state. Before creating it, you should at least make sure the code compiles. But how do you ensure you didn’t accidentally break something elsewhere in the system? Relying only on manual checks is risky.

This is where automation comes in. In this course we won’t set 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 configure a special workflow right on GitHub. Now, as soon as you push to your pull request, the magic happens:

1. GitHub Actions sees this event and starts your workflow.
2. It automatically builds the project and runs all tests.
3. If all tests pass, a green check mark 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’ll see a red cross. Merging such a PR into the main branch is strictly prohibited.

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

            subgraph Workflow
            C -- "Start" --> D[Run_tests]
            D --> E[Successful]
            D --> F[Failed]
            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 configure notifications. If the 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.