# Fusiones de solicitudes de extracción Aprenda estrategias para combinar solicitudes de incorporación de cambios, incluidas confirmaciones de fusión, fusiones con squash y operaciones de rebase, para administrar eficazmente el historial del repositorio. Las solicitudes de incorporación de cambios se pueden combinar de diferentes maneras. La mejor estrategia depende de qué aspecto quieras que tenga el historial del repositorio y de cuánto detalle quieras conservar de la rama de la solicitud de incorporación de cambios. | Strategy | Result | Elegir cuándo | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Confirmación de combinación | Conserva todas las confirmaciones de la rama de solicitud de incorporación de cambios y agrega un punto de combinación explícito. | Tu equipo valora el historial completo, o los commits individuales tienen sentido por sí solos. | | Squash y fusionar | Combina todas las confirmaciones de la solicitud de incorporación de cambios en una sola confirmación en la rama base. | Una solicitud de incorporación de cambios representa un cambio lógico, especialmente con muchas confirmaciones de corrección pequeñas. | | Rebase y fusionar | Agrega cada confirmación a la rama base sin una confirmación de combinación, para un historial lineal. | Tu equipo quiere un historial lineal y los commits ya están claramente organizados. | ## Combinación de confirmaciones Cuando haces clic en la opción **Combinar solicitud de incorporación de cambios** predeterminada en una solicitud de incorporación de cambios en GitHub.com, todas las confirmaciones de la rama de características se agregan a la rama base en una confirmación de fusión mediante combinación. La solicitud de incorporación de cambios se combina mediante [la opción`--no-ff`](https://git-scm.com/docs/git-merge#_fast_forward_merge). Para combinar las solicitudes de incorporación de cambios, debe tener [permisos de escritura](/es/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) en el repositorio. ![Diagrama de un flujo estándar de combinación y confirmación, donde las confirmaciones de una rama de características y una confirmación de combinación adicional se agregan a "main".](/assets/images/help/pull_requests/standard-merge-commit-diagram.png) Una confirmación de combinación conserva el historial de confirmaciones completo de la rama de solicitud de incorporación de cambios. Esto facilita la visualización de todas las confirmaciones que llevaron al cambio final, incluidas las correcciones de revisión y el trabajo intermedio. También crea un punto de combinación explícito en el historial de la rama base. Elija esta estrategia cuando los valores del equipo completen el historial o cuando las confirmaciones individuales en una solicitud de incorporación de cambios sean significativas por sí mismas. ## Squash y combinación de las confirmaciones Al seleccionar la opción de **fusión mediante combinación con "squash"** en una solicitud de incorporación de cambios en GitHub.com, las confirmaciones de la solicitud de incorporación de cambios se fusionan mediante combinación con "squash" en una única confirmación. En lugar de ver todas las confirmaciones individuales de un contribuyente de una rama de tema, las confirmaciones se combinan en una confirmación y se fusionan en la rama predeterminada. Las solicitudes de incorporación de cambios con confirmaciones con fusión mediante combinación con "squash" se combinan mediante la [opción de avance rápido](https://git-scm.com/docs/git-merge#_fast_forward_merge). Para fusionar las solicitudes de incorporación de cambios mediante combinación con "squash" y combinación, debe tener [permisos de escritura](/es/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) en el repositorio y el repositorio debe [permitir la fusión mediante combinación con "squash"](/es/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests). ![Diagrama de squash de confirmación, donde se combinan varias confirmaciones de una rama de características en una sola confirmación que se agrega a "main".](/assets/images/help/pull_requests/commit-squashing-diagram.png) Puedes combinar y fusionar para crear un historial Git más optimizado en tu repositorio. Los compromisos de trabajo en curso son útiles cuando se trabaja en una rama de característica, pero no son tan importantes para retenerlos en el historial Git. Si combinas estas confirmaciones en una única confirmación al fusionar con la rama predeterminada, los cambios se consolidan, lo que lleva a un historial Git claro. El squashing convierte todas las confirmaciones de la solicitud de incorporación de cambios en una confirmación en la rama base. Esto mantiene el historial de ramas predeterminado conciso y puede facilitar el examen más adelante. El inconveniente es que las confirmaciones intermedias de la solicitud de incorporación de cambios no se conservan como confirmaciones independientes en la rama base. Elija esta estrategia cuando una pull request represente un único cambio lógico, especialmente si la rama contiene muchos pequeños commits de corrección. ### Mensaje de fusión para una fusión de combinación Cuando haces squash y fusionas, GitHub genera un mensaje de confirmación de cambios predeterminado que puedes editar. El mensaje predeterminado puede incluir el título de la solicitud de incorporación de cambios, la descripción de la solicitud de incorporación de cambios o la información de confirmación, según la configuración del repositorio y el número de confirmaciones en la solicitud de incorporación de cambios. Los mantenedores y administradores pueden configurar el mensaje predeterminado para confirmaciones de squashed. Consulte [Configurar combinación de confirmaciones para las solicitudes de extracción](/es/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests). ### Combinar y fusionar una rama extensa La combinación de squash funciona mejor para ramas de corta duración. Si sigues trabajando en la misma rama de origen después de una fusión mediante squash, las solicitudes de extracción posteriores pueden incluir commits que ya se agruparon en la rama base. Esto puede aumentar la probabilidad de que se produzcan conflictos de fusión y obligarle a resolver los mismos conflictos más de una vez. Para las ramas de larga duración, considere usar un commit de fusión o hacer rebase de la rama antes de abrir la siguiente solicitud de extracción. ## Reorganizar y fusionar tus confirmaciones Al seleccionar la opción **reorganizar y fusionar** en una solicitud de extracción en GitHub.com, todas las confirmaciones de cambios de la rama temática (o rama de origen) se agregan individualmente a la rama base sin crear una confirmación de cambios de fusión. De este modo, el comportamiento de rebase y merge se asemeja a una [fusión fast-forward](https://git-scm.com/docs/git-merge#_fast_forward_merge) al mantener un historial lineal del proyecto. Sin embargo, el rebase lo logra al rescribir el historial de confirmaciones en la rama base con confirmaciones nuevas. El comportamiento de rebase y combinación en GitHub se desvía ligeramente desde `git rebase` fuera de GitHub. Vuelva a basar y combine en GitHub: * Actualiza siempre la información de quien realiza el commit y crea nuevos SHA de commit, mientras que `git rebase` no cambia esa información cuando el rebase se realiza sobre un commit ancestro. * Descarta commits que ya estaban vacíos de origen, como los creados con `git commit --allow-empty`, mientras que `git rebase` mantiene por defecto los commits originalmente vacíos. Para más información sobre `git rebase`, vea [git-rebase](https://git-scm.com/docs/git-rebase) en la documentación de Git. Para reorganizar la base y fusionar solicitudes de extracción, debe contar con [permisos de escritura](/es/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) en el repositorio, y el repositorio debe [permitir la fusión con reorganización de base](/es/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests). Para ver una representación visual de `git rebase`, consulte [el capítulo "Git Branching - Rebasing" del libro *Pro Git*](https://git-scm.com/book/en/v2/Git-Branching-Rebasing). La rebasificación agrega cada confirmación de la rama de solicitud de incorporación de cambios a la rama base sin crear una confirmación de combinación. Esto genera un historial lineal al tiempo que conserva las confirmaciones individuales de la solicitud de incorporación de cambios. Elija esta estrategia cuando su equipo quiera un historial lineal y los commits de la pull request ya estén bien organizados. Si GitHub no puede hacer rebase de la solicitud de extracción de forma segura automáticamente, puede hacer rebase localmente, resolver los conflictos y enviar la rama actualizada. Consulte [Resolving a merge conflict using the command line](/es/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) y [Merging a pull request](/es/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request). ## Combinaciones indirectas Una solicitud de incorporación de cambios se puede marcar como combinada si se puede acceder a sus confirmaciones de rama principal desde la rama base fuera de esa solicitud de incorporación de cambios. Esto puede ocurrir cuando los mismos commits se fusionan mediante otra pull request o se suben directamente a la rama predeterminada. Las combinaciones indirectas son poco frecuentes, pero pueden afectar a las expectativas de automatización y protección de ramas. Las solicitudes de extracción fusionadas indirectamente se marcan como `merged` aunque no se hayan cumplido las reglas de protección de la rama en esa solicitud de extracción. ## Lectura adicional * [Solicitudes de incorporación de cambios](/es/pull-requests/reference/pull-requests) * [Combinar y cerrar pull requests](/es/pull-requests/how-tos/merge-and-close-pull-requests)