About pull requests
Note: When working with pull requests, keep the following in mind:
- If you're working in the shared repository model, we recommend that you use a topic branch for your pull request. While you can send pull requests from any branch or commit, with a topic branch you can push follow-up commits if you need to update your proposed changes.
- Be very careful when force pushing commits to a pull request. Force pushing changes the repository history and can corrupt your pull request. If other collaborators branch the project before a force push, the force push may overwrite commits that collaborators based their work on.
You can create pull requests on GitHub.com, with GitHub Desktop, in Codespaces, on GitHub Mobile, and when using GitHub CLI.
After initializing a pull request, you'll see a review page that shows a high-level overview of the changes between your branch (the compare branch) and the repository's base branch. You can add a summary of the proposed changes, review the changes made by commits, add labels, milestones, and assignees, and @mention individual contributors or teams. For more information, see "Creating a pull request."
Once you've created a pull request, you can push commits from your topic branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.
Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.
After you're happy with the proposed changes, you can merge the pull request. If you're working in a shared repository model, you create a pull request and you, or someone else, will merge your changes from your feature branch into the base branch you specify in your pull request. For more information, see "Merging a pull request."
Si un repositorio requiere verificaciones de estado, éstas deben pasar antes de que fusiones tu rama con la rama protegida. Para obtener más información, consulta la sección "Acerca de las ramas protegidas".
Puedes vincular una solicitud de extracción a un informe de problemas para mostrar que se está trabajando en una solución y para cerrar automáticamente el informe de problemas cuando alguien fusione la solicitud de extracción. Para obtener más información, consulta la sección "Vincular una solicitud de extracción a un informe de problemas".
Tips:
- To toggle between collapsing and expanding all outdated review comments in a pull request, hold down OptionAltAlt and click Show outdated or Hide outdated. For more shortcuts, see "Keyboard shortcuts."
- You can squash commits when merging a pull request to gain a more streamlined view of changes. For more information, see "About pull request merges."
You can visit your dashboard to quickly find links to recently updated pull requests you're working on or subscribed to. For more information, see "About your personal dashboard."
Draft pull requests
Los borradores de solicitudes de cambio están disponibles en los repositorios públicos con GitHub Free para organizaciones y en los planes de facturación tradicionales por repositorio, y en los repositorios públicos y privados con GitHub Team, GitHub Enterprise Server 2.17+, y Nube de GitHub Enterprise.
When you create a pull request, you can choose to create a pull request that is ready for review or a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review draft pull requests. For more information about creating a draft pull request, see "Creating a pull request" and "Creating a pull request from a fork."
Cuando estés listo para obtener retroalimentación sobre tu solicitud de extracción, puedes marcar tu borrador de solicitud de extracción como listo para revisión. Con esto, solicitarás las revisiones de cualquier propietario de código en cuestión. You can convert a pull request to a draft at any time. For more information, see "Changing the stage of a pull request."
Differences between commits on compare and pull request pages
The compare and pull request pages use different methods to calculate the diff for changed files:
- Compare pages show the diff between the tip of the head ref and the current common ancestor (that is, the merge base) of the head and base ref.
- Pull request pages show the diff between the tip of the head ref and the common ancestor of the head and base ref at the time when the pull request was created. Consequently, the merge base used for the comparison might be different.
Further reading
- "Pull request" in the GitHub glossary
- "About branches"
- "Commenting on a pull request"
- "Closing a pull request"