Pregunta Git fusiona el maestro en la rama de características


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 branchched off master y algo de trabajo está hecho:

    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 hotfix

    git checkout master
    git branch hotfix1
    git checkout hotfix1
    
  5. El error se corrigió en la rama de revisión y se fusionó de nuevo en el maestro (quizás después de una solicitud de extracción / revisión del 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
    

Ahora mi pregunta: 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 los commits en mi rama de características? Quiero evitar recibir dos confirmaciones nuevas en mi rama de funciones que no tienen relación con la implementación de características. Esto especialmente me parece importante si uso las 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 una git merge master --ff-only: "fatal: no es posible adelantar, abortar", pero no estoy seguro si esto me ayudó.


591
2018-06-06 07:18


origen


Respuestas:


Debería poder volver a establecer la base de su sucursal en el maestro:

git checkout feature1
git rebase master

Administre todos los conflictos que surjan. Cuando llegue a los commits con las correcciones de errores (ya en master), git dirá que no hubo cambios y que tal vez ya se aplicaron. A continuación, continúe con la rebase (mientras omite las confirmaciones ya en el maestro) con

git rebase --skip

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

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


352
2018-06-06 07:24



¿Cómo fusionar la rama principal en la rama de características? 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. Usted se comprometió tanto en la rama de características como en la rama principal. Avance rápido es imposible ahora.

Mira esto 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 de flujo de trabajo que hacen cosas automáticamente que de otro modo tendrías que hacer manualmente.

Entonces, ¿qué hiciste en tu flujo de trabajo? Tienes dos ramas para trabajar, tu rama feature1 es básicamente la rama "develop" en el modelo de gitflow.

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

El modelo de gitflow le pide fusionar la revisión también con la rama de desarrollo, que es "feature1" 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 SOLAMENTE esos cambios. Podrían entrar en conflicto con otros cambios de desarrollo en la rama, pero no entrarán en conflicto con la rama maestra si fusionas la rama de características de nuevo para dominar eventualmente.

Ten mucho cuidado con el rebase. Solo rebase si los cambios que realizó permanecen en su repositorio local, p. no empujaste ninguna rama a otro repositorio. Rebasing es una gran herramienta para que organices tus compromisos locales en un orden útil antes de expandirlo al mundo, pero al volver a basarlo después se estropearán las cosas para los principiantes como tú.


698
2018-06-06 08:42



Basado en Este artículo debieras:

  • crear una nueva rama que se basa en la nueva versión del maestro
  • fusiona tu antigua rama de características en una nueva
  • resolver el conflicto en la nueva rama de características

De esta manera, su historia se mantiene clara porque no necesita fusionarse de nuevo. Y no necesitas ser tan súper cuidadoso ya que no necesitas git rebase


42
2018-06-09 14:16



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

1) Crear y cambiar a una nueva rama. Asegúrese de que la nueva rama se base en master por lo que incluirá 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 sucursal, combine los cambios desde su rama de características existente. Esto agregará sus confirmaciones sin duplicar las confirmaciones de revisiones.

git merge feature1

3) En la nueva rama, resuelva cualquier conflicto entre su función y la rama principal.

¡Hecho! Ahora usa la nueva rama para continuar desarrollando tu función.


12
2018-03-08 08:56



Es posible que pueda hacer una "selección de cereza" para sacar el exacto commit (s) que necesita en su rama de características.

Haz un git checkout hotfix1 para entrar en la rama hotfix1. Entonces haz una git log obtener el hash SHA1 (gran secuencia de letras al azar y números que identifican de manera única un commit) del commit en cuestión. Copia eso (o los primeros 10 o más caracteres).

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

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

Eso hará que ese compromiso, y solamente ese compromiso, en su rama de características. Ese cambio estará en la rama: usted simplemente lo "escogió". Luego, reanude el trabajo, edite, comprométalo, empuje, etc. para su satisfacción.

Cuando, finalmente, realice otra combinación de una rama en su rama de características (o viceversa), git reconocerá que ya se ha unido ese particular comprométase, sepa que no tiene que volver a hacerlo, y simplemente "omítalo".


8
2017-10-02 05:39