Digamos que tenemos la siguiente situación en Git:

1. Un repositorio creado:

   mkdir GitTest2
   cd GitTest2
   git init
   

2. Algunas modificaciones en el maestro tienen lugar y se comprometen:

   echo "On Master" > file
   git commit -a -m "Initial commit"
   

3. Feature1 se bifurcó del master y se realizó algún trabajo:

   git branch feature1
   git checkout feature1
   echo "Feature1" > featureFile
   git commit -a -m "Commit for feature1"
   

4. Mientras tanto, se descubre un error en el código maestro y se establece una rama de revisión:

   git checkout master
   git branch hotfix1
   git checkout hotfix1
   

5. El error se corrigió en la rama de revisión y se fusionó nuevamente en el maestro (tal vez después de una solicitud de extracción / revisión de código):

   echo "Bugfix" > bugfixFile
   git commit -a -m "Bugfix Commit"
   git checkout master
   git merge --no-ff hotfix1
   

6. El desarrollo en feature1 continúa:

   git checkout feature1
   

Digamos que necesito la revisión en mi rama de características, tal vez porque el error también ocurre allí. ¿Cómo puedo lograr esto sin duplicar las confirmaciones en mi rama de características?

Quiero evitar obtener dos nuevos commits en mi rama de características que no tienen relación con la implementación de características. Esto me parece especialmente importante si utilizo solicitudes de extracción: todas estas confirmaciones también se incluirán en la solicitud de extracción y deben revisarse aunque esto ya se haya hecho (ya que la revisión ya está en el maestro).

No puedo hacer un git merge master --ff-only: "fatal: no es posible avanzar rápidamente, abortar", pero no estoy seguro de si esto me ayudó.

¿Cómo fusionamos la rama maestra en la rama característica? Fácil:

git checkout feature1
git merge master

No tiene sentido forzar una fusión de avance rápido aquí, ya que no se puede hacer. Te comprometiste tanto en la rama de características como en la rama maestra. Avance rápido es imposible ahora.

Echa un vistazo a GitFlow . Es un modelo de ramificación para git que puede seguirse, e inconscientemente ya lo hizo. También es una extensión de Git que agrega algunos comandos para los nuevos pasos del flujo de trabajo que hacen las cosas automáticamente, que de lo contrario necesitaría hacer manualmente.

Entonces, ¿qué hiciste bien en tu flujo de trabajo? Tiene dos ramas para trabajar, su rama feature1 es básicamente la rama "desarrollo" en el modelo GitFlow.

Creó una rama de revisión de master y la fusionó de nuevo. Y ahora estás atrapado.

El modelo GitFlow le pide que combine la revisión también con la rama de desarrollo, que es "característica1" en su caso.

Entonces la verdadera respuesta sería:

git checkout feature1
git merge --no-ff hotfix1

Esto agrega todos los cambios que se realizaron dentro de la revisión a la rama de características, pero solo esos cambios. Pueden entrar en conflicto con otros cambios de desarrollo en la rama, pero no entrarán en conflicto con la rama maestra si finalmente fusiona la rama característica con la rama maestra.

Ten mucho cuidado con el rebase. Solo vuelva a redactar si los cambios que realizó permanecieron locales en su repositorio, por ejemplo, no empujó ninguna rama a otro repositorio. Rebasar es una gran herramienta para que usted organice sus compromisos locales en un orden útil antes de lanzarlo al mundo, pero el rebase posterior arruinará las cosas para los principiantes como usted.

Debería poder volver a basar su rama en master:

git checkout feature1
git rebase master

Gestiona todos los conflictos que surjan. Cuando llegues a los commits con las correcciones de errores (ya en master), Git dirá que no hubo cambios y que tal vez ya se aplicaron. Luego continúa el rebase (mientras omite los commits ya en master) con

git rebase --skip

Si realiza una git logen su rama de características, verá que la confirmación de corrección de errores aparece solo una vez, y en la parte maestra.

Para una discusión más detallada, eche un vistazo a la documentación del libro Git en git rebase( https://git-scm.com/docs/git-rebase ) que cubre este caso de uso exacto.

================ Editar para contexto adicional ====================

Esta respuesta se proporcionó específicamente para la pregunta formulada por @theomega, teniendo en cuenta su situación particular. Tenga en cuenta esta parte:

Quiero evitar [...] confirmaciones en mi rama de características que no tienen relación con la implementación de características.

Rebasar su rama privada en master es exactamente lo que dará ese resultado. Por el contrario, fusionar master en su rama haría precisamente lo que él específicamente no quiere que suceda : agregar una confirmación que no esté relacionada con la implementación de la función en la que está trabajando a través de su rama.

Para dirigirse a los usuarios que leen el título de la pregunta, omita el contenido real y el contexto de la pregunta, y luego solo lea la respuesta superior a ciegas, suponiendo que siempre se aplique a su (diferente) caso de uso, permítame explicar:

• solo rebase las ramas privadas (es decir, que solo existen en su repositorio local y no se han compartido con otros). Rebasar las ramas compartidas "rompería" las copias que otras personas puedan tener.
• si desea integrar los cambios de una rama (ya sea maestra u otra rama) en una rama que es pública (por ejemplo, presionó la rama para abrir una solicitud de extracción, pero ahora hay conflictos con la maestra y necesita actualizar su rama para resolver esos conflictos) necesitará fusionarlos (por ejemplo, con git merge masterla respuesta de @ Sven).
• también puede fusionar sucursales en sus sucursales privadas locales si así lo prefiere, pero tenga en cuenta que dará como resultado compromisos "extranjeros" en su sucursal.

Finalmente, si no está satisfecho con el hecho de que esta respuesta no es la más adecuada para su situación a pesar de que fue para @theomega, agregar un comentario a continuación no será particularmente útil: no controlo qué respuesta está seleccionada, solo @theomega lo hace.

Según este artículo , debe:

• crear una nueva rama que se basa en la nueva versión del maestro

  git branch -b newmaster

• fusionar su antigua rama de características en una nueva

  git checkout newmaster

• resolver conflictos en la nueva rama de características

Los dos primeros comandos se pueden combinar con git checkout -b newmaster.

De esta manera, su historial permanece claro porque no necesita fusiones anteriores. Y no necesita ser tan cauteloso ya que no necesita hacer un cambio de versión de Git.

git merge

puedes seguir los siguientes pasos

1. fusionar origin/masterrama a featurerama

# step1: change branch to master, and pull to update all commits
$ git checkout master
$ git pull

# step2: change branch to target, and pull to update commits
$ git checkout feature
$ git pull

# step3: merge master to feature(⚠️ current is feature branch)
$ git merge master

2. fusionar featurerama a origin/masterrama

origin/master es la rama maestra remota, mientras master es la rama maestra local

$ git checkout master
$ git pull origin/master

$ git merge feature
$ git push origin/master

La respuesta de Zimi describe este proceso en general. Aquí están los detalles:

1. Crea y cambia a una nueva sucursal. Asegúrese de que la nueva rama se base masterpara que incluya las revisiones recientes.

   git checkout master
   git branch feature1_new
   git checkout feature1_new
   
   # Or, combined into one command:
   git checkout -b feature1_new master
   

2. Después de cambiar a la nueva rama, combine los cambios de su rama de características existente. Esto agregará sus confirmaciones sin duplicar las confirmaciones de revisión.

   git merge feature1
   

3. En la nueva rama, resuelva cualquier conflicto entre su característica y la rama maestra.

¡Hecho! Ahora use la nueva rama para continuar desarrollando su función.

Aquí hay un script que puede usar para fusionar su rama maestra en su rama actual.

El script hace lo siguiente:

• Cambia a la rama maestra
• Tira de la rama maestra
• Vuelve a su sucursal actual
• Fusiona la rama maestra en su rama actual

Guarde este código como un archivo por lotes (.bat) y coloque el script en cualquier lugar de su repositorio. Luego haga clic en él para ejecutarlo y listo.

:: This batch file pulls current master and merges into current branch

@echo off

:: Option to use the batch file outside the repo and pass the repo path as an arg
set repoPath=%1
cd %repoPath%

FOR /F "tokens=*" %%g IN ('git rev-parse --abbrev-ref HEAD') do (SET currentBranch=%%g)

echo current branch is %currentBranch%
echo switching to master
git checkout master
echo.
echo pulling origin master
git pull origin master
echo.
echo switching back to %currentBranch%
git checkout %currentBranch%
echo.
echo attemting merge master into %currentBranch%
git merge master
echo.
echo script finished successfully
PAUSE

Es posible que pueda hacer una "selección de cereza" para extraer exactamente confirmaciones que necesita en su rama de características.

Haga un git checkout hotfix1para llegar a la rama hotfix1. Entonces haz ungit log para obtener el hash SHA-1 (secuencia grande de letras y números aleatorios que identifica de forma exclusiva una confirmación) de la confirmación en cuestión. Copie eso (o los primeros 10 caracteres).

Entonces, git checkout feature1 para volver a su rama de características.

Entonces, git cherry-pick <the SHA-1 hash that you just copied>

Eso tirará de ese compromiso, y solo esa confirmación, a su rama de características. Ese cambio estará en la rama: simplemente lo "seleccionó". Luego, reanude el trabajo, edite, confirme, presione, etc. a su gusto.

Cuando, finalmente, realice otra fusión de una rama en su rama de características (o viceversa), Git reconocerá que ya se ha fusionado en esa confirmación en particular , sabrá que no tiene que volver a hacerlo, y solo "saltearlo".

Estoy en la rama de características e hice refactorizaciones. Quiero fusionar los cambios maestros ahora a mi rama de características. Estoy muy atrasado. Tenga en cuenta que no quiero extraer los cambios maestros a mi local porque mis ramas de características tienen módulos movidos de un lugar a otro. Descubrí que solo realizar a continuación sin tirar no funciona. dice "Ya actualizado".

 //below does not get the latest from remote master to my local feature branch without git pull
    git checkout master 
    git fetch 
    git checkout my-feature-branch 
    git merge master

Esto funciona a continuación, tenga en cuenta el uso de git merge origin / master:

 git checkout master 
    git fetch 
    git checkout my-feature-branch 
    git merge origin/master