Git commits apparaissent dans toutes les twigs, pas seulement celles que je spécifie

Cela peut être un problème assez simple avec comment j'utilise git ou comment je l'intègre avec Visual Studio 2012. J'ai (ou je pensais avoir) deux twigs principales: maîsortingser et développer.

Je touche rarement la twig master, je fais surtout des commits à la twig develop et quand j'atteins un jalon je fusionne la twig develop avec la twig master. Si j'introduis une nouvelle fonctionnalité, je crée une nouvelle twig feat / SomeFeature à partir de la twig develop. Lorsque cette fonctionnalité est terminée, je la fusionne avec la twig develop et la fusionne ensuite avec la twig master.

Changer de twig fait exactement ce que je m'attends à faire, je vois les vieilles versions intactes du code. Cependant, lorsque j'ouvre le repo dans un programme de visualisation de twig, il apparaît que tous mes commits sont tous le long d'une twig:

entrez la description de l'image ici

Je m'attendais à voir des loops et des fusions, comme dans cette capture d'écran: entrez la description de l'image ici

Pourquoi mes twigs apparaissent-elles différentes? Pourquoi tous mes commits apparaissent-ils le long d'une twig?

Solutions Collecting From Web of "Git commits apparaissent dans toutes les twigs, pas seulement celles que je spécifie"

Que se passe-t-il

Il est difficile de savoir exactement ce qui se passe sans plus d'informations, mais vous obtiendrez probablement des fusions rapides . Fondamentalement, si Git peut aplatir une fusion, il le fait par défaut. Votre stream de travail de travail principalement dans develop et merge à plusieurs resockets dans le master vous prédispose à l'avance rapide des fusions.

(Notez qu'il n'y a rien de fondamentalement faux avec la fusion rapide vers l'avant.Certains développeurs adorent ce stream et font de leur mieux pour utiliser cette stratégie de fusion en rebase leur travail avant de merge.Autres développeurs, moi inclus, aiment voir "merge" bulles "pour les fusions de fonctionnalités.)

À titre d'exemple, considérez le graphique de validation suivant:

 [master] A---B---C \ [develop] D---E---F 

master contient les commits A , B et C develop contient les commits A , B , C , D , E et F

À ce stade, si vous fusionnez develop en master Git sera par défaut une fusion rapide, ce qui entraîne

 [master] [develop] A---B---C---D---E---F 

Cela se produit parce que la fusion entraînerait logiquement les mêmes validations existant dans les deux trees: Vous fusionnez les commits D , E et F sur une twig qui contient déjà A , B et C

Si le graphique précédent avait l'air différent, par exemple

 [master] A---B---C---G \ [develop] D---E---F 

quelque chose de différent arriverait. Vous finiriez avec quelque chose comme ceci:

 [master] A---B---C---G-------H \ / [develop] D---E---F 

Dans ce cas, vous obtenez un nouveau commit H, appelé commit de fusion .

Garder les bulles de fusion

Vous pouvez forcer le dernier comportement en utilisant l'indicateur --no-ff pour git merge . (Il y a aussi un drapeau --ff-only pour forcer le comportement opposé.) Dans le premier exemple, un git checkout master && git merge --no-ff develop résulterait en quelque chose comme ça

 [master] A---B---C-----------G \ / [develop] D---E---F 

Notez le nouveau commit de fusion G

Visual Studio

Tout cela est du sharepoint vue de Git sur la command line, mais je remarque que vous utilisez Visual Studio. Je ne suis pas sûr comment triggersr l'option --no-ff de merge à partir de VS, en supposant que vous effectuez vos fusions à partir de cet outil. Malheureusement, de nombreux clients charts Git cachent des options très utiles comme ce drapeau.