Comment créer la branche à partir d'un commit spécifique dans une branche différente

Si vous utilisez cette forme de la commande branch (avec point de départ), peu importe où se trouve votre HEAD.

Ce que vous faites:

git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8

• Tout d'Abord, vous définissez votre HEAD à la direction générale dev,

• Deuxièmement, vous démarrez une nouvelle branche de commettre 07aeec98. Il n'y a pas de bb.txt à ce commit (selon votre repo github).

Si vous voulez commencer une nouvelle branche à l'endroit que vous venez de vérifier,, vous pouvez soit exécuter une branche sans point de départ:

git branch test

Ou comme d'autres ont répondu, branche et caisse là-bas dans une opération:

git checkout -b test

Je pense que vous pourriez être confus par le fait que 07aeec98 fait partie de la branche dev. Il est vrai que cette validation est un ancêtre de dev, ses changements sont nécessaires pour atteindre le dernier commit dans dev. Cependant, ce sont d'autres commits qui sont nécessaires pour atteindre le dernier dev, et ceux-ci ne sont pas nécessairement dans l'histoire de 07aeec98.

8480e8ae (où vous avez ajouté bb.txt) n'est par exemple pas dans l'histoire de 07aeec98. Si vous vous branchez à partir de 07aeec98, vous n'obtiendrez pas les modifications introduites par 8480e8ae.

En d'autres termes: si vous fusionnez la branche A et la branche B dans la branche C, créez une nouvelle branche sur un commit de A, vous n'obtiendrez pas les modifications introduites dans B.

De même ici, vous aviez deux branches parallèles master et dev, que vous avez fusionnées dans dev. Ramification à partir d'un commit de master (plus ancien que la fusion) ne vous fournira pas les changements de dev.

Si vous souhaitez intégrer définitivement les nouvelles modifications de master dans vos branches d'entités, vous devez fusionner master dans celles-ci et continuer. Cela créera des commits de fusion dans vos branches d'entités.

Si vous n'avez pas publié vos branches d'entités, vous pouvez également les rebaser sur le maître mis à jour: git rebase master featureA. Soyez prêt à résoudre d'éventuels conflits.

Si vous voulez un workflow où vous pouvez travailler sur feature les branches libres de Merge commits et s'intègrent toujours avec des changements plus récents dans master, je recommande ce qui suit:

• basez chaque nouvelle branche de fonctionnalité sur un commit de master
• créez une branche dev sur un commit de master
• lorsque vous avez besoin de voir comment votre branche d'entité s'intègre aux nouvelles modifications de master, fusionnez master et la branche d'entité dans dev.

Ne commettez pas directement dans dev, utilisez-le Uniquement pour fusionner d'autres branches.

Pour exemple, si vous travaillez sur les entités A et B:

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

Fusionnez les branches dans une branche dev pour vérifier si elles fonctionnent bien avec le nouveau maître:

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

Vous pouvez continuer à travailler sur vos branches d'entités et continuer à fusionner régulièrement les nouvelles modifications des branches master et feature dans dev.

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

Quand il est temps d'intégrer les nouvelles fonctionnalités, de fusionner les branches (pas dev!) en master.