# Fusiones de solicitudes de incorporación de cambios Descubre estrategias para fusionar solicitudes de incorporación de cambios, como las confirmaciones de fusión, las fusiones squash y las rebases, con el fin de administrar el historial del repositorio de forma eficaz. Las solicitudes de incorporación de cambios se pueden fusionar de diferentes maneras. La mejor estrategia depende de cómo quiera tu equipo que sea el historial del repositorio y de cuántos detalles quieras conservar de la rama de la solicitud de extracción. | Strategy | Result | Elegir cuándo | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Confirmación de combinación | Conserva todas las confirmaciones de la rama de la solicitud de extracción y añade un punto de fusión explícito. | Tu equipo valora el historial completo, o las confirmaciones individuales son significativas por sí mismas. | | Aplastar y fusionar | Combina todas las confirmaciones de la solicitud de incorporación de cambios en una única confirmación en la rama base. | Una solicitud de incorporación de cambios representa un único cambio lógico, especialmente cuando hay muchas confirmaciones pequeñas de corrección. | | Rebasar 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 tu instancia de GitHub Enterprise Server, 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/enterprise-server@3.18/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 fusión conserva el historial completo de confirmaciones de la rama de la solicitud de incorporación de cambios. Esto facilita la visualización de todas las confirmaciones que condujeron 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. Elige esta estrategia cuando tu equipo valore el historial completo o cuando las confirmaciones individuales de una solicitud de incorporación de cambios tengan sentido 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 tu instancia de GitHub Enterprise Server, 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/enterprise-server@3.18/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/enterprise-server@3.18/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. La fusión convierte todas las confirmaciones de la solicitud de incorporación de cambios en una sola confirmación en la rama base. Esto mantiene el historial de ramas predeterminado conciso y puede facilitar el examen más adelante. La desventaja es que las confirmaciones intermedias de la solicitud de incorporación de cambios no se conservan como confirmaciones independientes en la rama base. Elige esta estrategia cuando una solicitud de incorporación de cambios represente un único cambio lógico, especialmente si la rama incluye muchas pequeñas confirmaciones de corrección. ### Mensaje de fusión para una fusión de combinación Al fusionar mediante squash, GitHub genera un mensaje de confirmación 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 las confirmaciones fusionadas mediante squash. Consulte [Configurar combinación de confirmaciones para las solicitudes de extracción](/es/enterprise-server@3.18/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 fusión mediante squash funciona mejor con ramas de corta duración. Si sigues trabajando en la misma rama principal tras una fusión con comits agrupados, las solicitudes de incorporación de cambios posteriores pueden incluir comits que ya se hayan agrupado 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 ramas de larga duración, considera utilizar un commit de fusión o rebasar la rama antes de abrir la siguiente solicitud de incorporación de cambios. ## Reorganizar y fusionar tus confirmaciones Al seleccionar la opción **Fusionar mediante cambio de base** en una solicitud de incorporación de cambios, todas las confirmaciones de la rama de tema (o rama de encabezado) se agregan a la rama base por separado sin una confirmación de combinación. De este modo, el comportamiento de fusionar mediante cambio de base y combinar es similar a una [combinación de avance rápido](https://git-scm.com/docs/git-merge#_fast_forward_merge), ya que mantiene un historial de proyectos lineal. 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. Cambie de base y combine en GitHub: * Actualiza siempre la información de quien confirma y crea nuevos SHA de confirmación, mientras que `git rebase` no cambia esa información cuando el cambio de base se realiza sobre una confirmación de antepasado. * 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 fusionar mediante cambio de base y combinar solicitudes de incorporación de cambios, debe tener [permisos de escritura](/es/enterprise-server@3.18/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 combinación de fusión mediante cambio de base](/es/enterprise-server@3.18/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests). Para obtener una representación visual de `git rebase`, vea [el capítulo "Git Branching - Rebasing" (Creación de ramas en Git: fusión mediante cambio de base) del libro *Pro Git*](https://git-scm.com/book/en/v2/Git-Branching-Rebasing). El rebasado añade cada commit de la rama de la solicitud de incorporación de cambios a la rama base sin crear un commit de fusión. Esto genera un historial lineal al tiempo que conserva las confirmaciones individuales de la solicitud de extracción. 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 rebasar de forma segura la solicitud de extracción automáticamente, puedes rebasar localmente, resolver los conflictos y enviar la rama actualizada. Consulte [Resolving a merge conflict using the command line](/es/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) y [Combinación de una solicitud de incorporación de cambios](/es/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request). ## Combinaciones indirectas Una solicitud de extracción se puede marcar como fusionada si se puede acceder a las confirmaciones de su rama principal desde la rama base fuera de dicha solicitud de extracción. 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` incluso si no se cumplieron las reglas de protección de ramas de dicha solicitud de extracción. ## Lectura adicional * [Solicitudes de incorporación de cambios](/es/enterprise-server@3.18/pull-requests/reference/pull-requests) * [Combinar y cerrar pull requests](/es/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests)