Cómo crear la rama a partir de una confirmación específica en una rama diferente

Question

He realizado varias confirmaciones en la rama maestra y luego las he fusionado con la rama dev.

Quiero crear una rama a partir de una confirmación específica en la rama de desarrollo, que primero se confirmó en la rama principal.

que utilizan los comandos:

git checkout dev 
git branch <branch name> <commit id> 

Sin embargo, esto crea la rama de la rama principal, no la rama dev que esperaba. La identificación de confirmación es la misma en la rama principal y en la rama dev. Entonces, ¿cómo puedo distinguir la misma identificación de confirmación en otra rama?

PD: Hice un ejemplo en github aquí https://github.com/RolandXu/test_for_branch

que utiliza los comandos:

git checkout dev 
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8 

Lo que espero es que la rama de prueba contiene aa.txt cc.txt bb.txt. Sin embargo, la rama de prueba solo contiene aa.txt y cc.txt. Lo más probable es que haya creado la rama de la rama principal.

Answer 1

Si está utilizando esta forma del comando branch (con punto de inicio), no importa dónde se encuentre su HEAD.

Lo que está haciendo:

git checkout dev 
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8 

• En primer lugar, se establece su HEAD a la rama dev,

• En segundo lugar, se inicia una nueva rama de cometer 07aeec98. No hay bb.txt en este compromiso (de acuerdo con su repositorio github).

Si desea iniciar una nueva rama en la ubicación que acaban de realizado el pedido, Puede rama funcionar sin un punto de inicio:

git branch test 

o como otros han contestado, rama y la salida allí en una sola operación:

git checkout -b test 

---

creo que podría ser co nfused por el hecho de que 07aeec98 es parte de la rama dev. Es cierto que este compromiso es un antecesor de dev, se necesitan sus cambios para llegar a la última confirmación en dev. Sin embargo, son otros commits necesarios para llegar al último dev, y estos no están necesariamente en el historial de 07aeec98.

8480e8ae (donde ha agregado bb.txt) es por ejemplo, no en el historial de 07aeec98. Si se bifurca desde 07aeec98, no recibirá los cambios introducidos por 8480e8ae.

En otras palabras: si combina rama A y B rama en rama C, a continuación, crear una nueva rama en una confirmación de una, usted no consigue los cambios introducidos en B.

mismo aquí, tenía dos ramas 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 permanentemente integrar nuevos cambios de maestro en sus ramas de características, debe fusionar master en ellos y seguir adelante. Sin embargo, esto creará confusiones de fusión en sus ramas de características.

Si no ha publicado sus ramas de características, también puede volver a establecerlas en el maestro actualizado: git rebase master featureA. Prepárate para resolver posibles conflictos.

Si desea un flujo de trabajo donde se puede trabajar en las ramas función gratuita de fusión compromete y todavía integrarse con los nuevos cambios en el maestro, recomiendo lo siguiente:

• base de cada nueva rama de la característica en un compromiso del maestro
• crear una rama dev comprometerse en un maestro de
• cuando se necesita para ver cómo su rama de la característica se integra con los nuevos cambios en el maestro, fusionar el maestro y la rama de la característica en dev.

No confíe en dev directamente, utilícelo solamente para unir otras ramas.

Por ejemplo, si se está trabajando en función de A y B:

a---b---c---d---e---f---g -master 
    \  \ 
    \  \-x -featureB 
     \ 
     \-j---k -featureA 

ramas se funden en una rama dev para comprobar si funcionan bien con el nuevo maestro:

a---b---c---d---e---f---g -master 
    \  \   \ 
    \  \   \--x'---k' -dev 
     \  \   // 
     \  \-x---------- / -featureB 
     \     /
     \-j---k--------------- -featureA 

Puede siga trabajando en sus ramas de características y siga fusionándose en los nuevos cambios de las ramas principal y de funciones en dev regularmente.

a---b---c---d---e---f---g---h---i----- -master 
    \  \   \   \ 
    \  \   \--x'---k'---i'---l' -dev 
     \  \   //  /
     \  \-x---------- /  /-featureB 
     \     /  / 
     \-j---k-----------------l------ -featureA 

Cuando es hora de integrar las nuevas funciones, fusionar las ramas de características (no dev!) En maestro.

Answer 2

Trate

git checkout <commit hash> 
git checkout -b new_branch 

La confirmación debería existir solamente una vez en su árbol, no en dos ramas separadas.

Esto le permite verificar esa confirmación específica y nombrarla como prefiera.

Answer 3

Usted tiene los argumentos en el orden equivocado:

git branch <branch-name> <commit> 

y por eso, no importa qué rama está desprotegido; Hará lo que dices. (Si se omite el argumento de cometer, el valor predeterminado es la creación de una rama en el mismo lugar que la actual.)

Si quieres echa un vistazo a la nueva rama medida que lo crea:

git checkout -b <branch> <commit> 

con el mismo comportamiento si omite el argumento de compromiso.

Answer 4

que tiene que hacer:

git branch <branch_name> <commit> 

(que estaba intercambiando el nombre de la sucursal y se comprometan)

o puede hacerlo:

git checkout -b <branch_name> <commit> 

Si en lugar de que utilice nombre de la sucursal , obtienes una rama de la punta de la rama.