En bref: la meilleure pratique consiste à créer des branches, à fusionner souvent et à rester synchronisées .
Il existe des conventions assez claires sur la conservation de votre code dans des branches distinctes de la branche principale:
- Vous êtes sur le point de mettre en œuvre des changements majeurs ou perturbateurs
- Vous êtes sur le point d'effectuer des modifications qui pourraient ne pas être utilisées
- Vous voulez expérimenter quelque chose que vous n'êtes pas sûr que cela fonctionnera
- Quand on vous dit de vous diversifier, les autres peuvent avoir quelque chose à faire en mode maître
En règle générale, après la création d'une branche, vous devez rester synchronisé avec la branche principale. Parce que finalement vous devez le fusionner pour le maîtriser. Afin d'éviter un désordre compliqué de conflits lors de la fusion, vous devez commettre souvent, fusionner souvent.
Bonnes pratiques à suivre
Un modèle de branchement Git réussi par Vincent Driessen a de bonnes suggestions. Si ce modèle de branchement vous intéresse, envisagez l' extension de flux à git . D'autres ont commenté sur le flux .
Pratiques de marquage
Comme vous le savez déjà, Git vous donne des identifiants de commit tels que 1.0-2-g1ab3183 mais ce ne sont pas des tags! Le balisage est effectué avec la balise git, et les balises créées à l'aide de la balise git constituent la base des identificateurs de validation créés par git describe. En d'autres termes, dans Git, vous ne marquez pas les branches. Vous étiquetez les commits. Il est correct de dire que la balise est juste un pointeur annoté sur un commit.
Regardons un exemple pratique qui l’a démontré,
/ - [v1.0]
v
---. ---. --- .--- S ---.--- Un <- maître
\
\ -.--- B <- test
Commençons par «S» avec la balise 'v1.0'. Ce commit est à la fois sur le "maître" de la branche et sur le "test" de la branche. Si vous exécutez " git decrire " en plus du commit 'A' (en haut de la branche 'master'), vous obtiendrez quelque chose comme v1.0-2-g9c116e9. Si vous exécutez "git describe" en plus du commit 'A' (c'est-à-dire la branche 'test'), vous obtiendrez quelque chose du genre v1.0-2-g3f55e41, c'est le cas de la configuration par défaut de git-describe. Notez que ce résultat est légèrement différent. v1.0-2-g9c116e9signifie que nous sommes au commit avec SHA-1 trié id de 9c116e9, 2 commits après tag v1.0. Il n'y a pas de tag v1.0-2!
Si vous souhaitez que votre balise n'apparaisse que sur la branche 'maître', vous pouvez créer un nouveau commit (par exemple, ne mettre à jour que les informations de version par défaut / de secours dans GIT-VERSION-FILE) après le point de branchement de la branche 'test'. Si vous marquez les commits sur une branche 'test' avec par exemple 'v1.0.3`, cela ne sera visible que depuis' test '.
Références
J'ai trouvé beaucoup, beaucoup de blogs et de messages utiles pour apprendre. Cependant, ceux qui sont illustrés professionnellement sont rares. Ainsi, je voudrais recommander un post - Un modèle de branchement Git réussi par @nvie. J'ai emprunté son illustration :)
Une branche est utilisée si vous avez 2 versions différentes du référentiel en même temps. Une balise est un moyen de marquer un point dans le temps dans votre référentiel.
Vous devez ajouter une balise pour marquer une version publiée. Si vous devez ensuite corriger le bogue de cette version, vous créerez une branche au niveau de la balise.
Vous souhaitez uniquement supprimer les branches qui ont été fusionnées dans HEAD [ou dans une autre branche].
la source