7. Pull Request

Leer en español

A Pull Request (PR), Merge Request on other Git hosts, is a request for a project's maintainers to review and merge your changes. It's the standard process for contributing to a project, or the heart of collaboration in open source.

The maintainers will review your PR, make comments, request changes, or approve and merge it.

Very rarely does a PR get merged without asking you for changes first. Don't take it the wrong way, the reviewer knows the project better than you and wants to keep the code quality high.

Open a Pull Request

  1. Go to your fork on GitHub
  2. You'll see a "Compare & pull request" message - click it
  3. Complete the PR form
  4. Click "Create pull request"

In summary, the full flow for creating a Pull Request would be:

  1. Create a fork of the project (if you haven't already; otherwise you should sync your fork first).
  2. Clone your fork locally (or use the one you already have).
  3. Create a specific branch for your change (NEVER work directly on main).
  4. Make your changes: small, focused commits with clear descriptions.
  5. Push to your branch in your fork.
  6. From GitHub, open a Pull Request from your branch to the main branch of the original repository.
  7. Wait for the review, respond to comments and make changes if necessary.

There's a very common convention for naming branches, as follows:

  • feature/description: New feature
  • fix/description: Bug fix
  • docs/description: Documentation changes
  • refactor/description: Code refactoring
  • test/description: Add or improve tests

But it's not mandatory; each project can have its own conventions. What matters is that the name is descriptive. A clear, concise text that explains the "why" behind the changes. If you also include screenshots, videos and references to issues, all the better.

Then the review process begins, where you'll receive comments, suggestions and possibly change requests.

Be polite and grateful. Many maintainers are doing this in their free time. Their goal is to improve the project, not to criticize you personally.

Making changes to an existing PR

If the reviewer asks you for changes, keep working on the same branch you used for the PR. New commits will be added to the PR automatically.

Activity 1

Practice with a test repository:

  1. Create a repository called pr-practice on your GitHub.
  2. Clone the repo and create a CONTRIBUTORS.md file.
  3. Add your name to the file.
  4. Commit and push.
  5. Create a new branch feature/add-info.
  6. Add more information (your GitHub profile, projects, etc.).
  7. Push the branch.
  8. Create a Pull Request from the branch to main.
  9. Review and merge your own PR.
Activity 2

Real contribution:

  1. Find a project with an issue marked "good first issue".
  2. Comment on the issue that you'd like to work on it.
  3. Fork the project.
  4. Create an appropriate branch.
  5. Implement the solution.
  6. Test your changes.
  7. Create a PR with a complete description.
  8. Respond to any feedback.

This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.

Building SPAs with Django and HTML Over the Wire: Learn to build real-time single page applications with Python

Building SPAs with Django and HTML Over the Wire: Learn to build real-time single page applications with Python

The HTML over WebSockets approach simplifies single-page application (SPA) development and lets you bypass learning a JavaScript rendering framework such as React, Vue, or Angular, moving the logic to Python. This web application development book provides you with all the Django tools you need to simplify your developments with real-time results.

Buy the book

Help me keep writing

Every coffee gives me a push toward the next article.

Ko-fi donationsSure, it's on me!

Comments

There are no comments yet.