Realicé varias confirmaciones en la twig maestra y luego las fusioné con la twig dev.
Quiero crear una twig a partir de una confirmación específica en la twig de desarrollo, que primero se cometió en la twig principal.
Usé los commands:
git checkout dev git branch <branch name> <commit id> Sin embargo, esto crea la twig de la twig principal, no la twig de desarrollo que esperaba. La identificación de confirmación es la misma en la twig principal y en la twig dev. Entonces, ¿cómo puedo distinguir la misma identificación de compromiso en una twig diferente?
PD: hice un ejemplo en github aquí https://github.com/RolandXu/test_for_branch
Usé los commands:
git checkout dev git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
Lo que espero es que la twig de testing contenga aa.txt bb.txt cc.txt. Sin embargo, la twig de testing solo contiene aa.txt y cc.txt. Lo más probable es que haya creado la twig de la twig principal.
Si está utilizando esta forma del command de branch (con punto de inicio), no importa dónde esté su HEAD .
Qué estás haciendo:
git checkout dev git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
Primero, configura tu HEAD para el desarrollo de la twig,
En segundo lugar, comienza una nueva twig en commit 07aeec98 . No hay bb.txt en este compromiso (de acuerdo con su repository github).
Si desea iniciar una nueva sucursal en la location que acaba de retirar, puede ejecutar una bifurcación sin punto de inicio:
git branch test
o como otros han respondido, bifurcar y pagar allí en una sola operación:
git checkout -b test
Creo que puede estar confundido por el hecho de que 07aeec98 es parte de la twig dev . Es cierto que este compromiso es un antecesor de dev , se necesitan sus cambios para alcanzar el último commit en dev . Sin embargo, son otras confirmaciones necesarias para llegar al último desarrollador, y estas no están necesariamente en la historia de 07aeec98 .
8480e8ae (donde agregó bb.txt) no está, por ejemplo, en el historial de 07aeec98 . Si se ramifica desde 07aeec98 , no obtendrá los cambios introducidos por 8480e8ae .
En otras palabras: si fusionas la twig A y la twig B con la twig C, creas una nueva twig en una confirmación de A, no obtendrás los cambios introducidos en B.
Lo mismo aquí, tenías dos twigs paralelas master y dev, que fusionaste en dev. La bifurcación de una confirmación de maestro (anterior a la combinación) no le proporcionará los cambios de dev.
Si desea integrar de forma permanente nuevos cambios de maestro en sus twigs de características, debe fusionar el master en ellos y continuar. Sin embargo, esto creará confusiones de fusión en sus twigs de características.
Si no ha publicado sus twigs de características, también puede volver a establecer las bases en el maestro actualizado: git rebase master featureA . Prepárate para resolver posibles conflictos.
Si desea un flujo de trabajo en el que pueda trabajar en twigs de funciones sin compromisos de fusión e integrarlo con cambios más recientes en el máster, recomiendo lo siguiente:
dev en una confirmación de maestro dev . No se comprometa directamente con dev , utilícelo solo para fusionar otras twigs.
Por ejemplo, si está trabajando en la característica A y B:
a---b---c---d---e---f---g -master \ \ \ \-x -featureB \ \-j---k -featureA
Combina twigs en una twig de desarrollo para verificar si funcionan bien con el nuevo maestro:
a---b---c---d---e---f---g -master \ \ \ \ \ \--x'---k' -dev \ \ / / \ \-x---------- / -featureB \ / \-j---k--------------- -featureA
Puede seguir trabajando en sus twigs de características y seguir fusionándose en nuevos cambios tanto de las twigs principales como de las funciones en dev regularidad.
a---b---c---d---e---f---g---h---i----- -master \ \ \ \ \ \ \--x'---k'---i'---l' -dev \ \ / / / \ \-x---------- / / -featureB \ / / \-j---k-----------------l------ -featureA
Cuando sea el momento de integrar las nuevas características, combine las twigs de características (¡no dev !) En el maestro.
Tienes los arguments en el order incorrecto:
git branch <branch-name> <commit>
y para eso, no importa qué twig esté desprotegida; Hará lo que dices. (Si omite el argumento de compromiso, se establece por defecto para crear una twig en el mismo lugar que la actual).
Si desea verificar la nueva twig al crearla:
git checkout -b <branch> <commit>
con el mismo comportamiento si omite el argumento de compromiso.
Tu tienes que hacer:
git branch <branch_name> <commit>
(Estabas intercambiando el nombre de la twig y el commit)
O puedes hacer:
git checkout -b <branch_name> <commit>
Si en lugar de usar el nombre de la twig, obtiene una twig de la punta de la twig.
Tratar
git checkout <commit hash> git checkout -b new_branch
La confirmación solo debería existir una vez en tu tree, no en dos twigs separadas.
Esto le permite verificar esa confirmación específica y darle el nombre que desee.