Questions sur Git Flow

Question

Nous utilisons essentiellement le flux Git documenté ici: http://nvie.com/posts/a-successful-git-branching-model/. Maintenant, quelques questions ont été soulevées par les développeurs:

1. D'où sortons-nous le code en production? La branche release/hotfix ou le master?
2. Nécessité de restaurer dans la branche de publication, si certaines fonctionnalités de la branche de publication actuelle ne sont plus requises.
3. Nous disons que la branche de publication sera verrouillée uniquement à la piste, aucun changement de code ne sera effectué ici. Ceci est dévié du Git Flow, et je ne sais pas pourquoi.

Foire aux questions:

1. S'il n'y a pas de changement dans la branche de sortie, pourquoi avons-nous besoin d'une même? Je viens du monde ClearCase et j'ai toujours l'impression qu'une branche n'est pas nécessaire s'il n'y a pas de changement.
2. Pourquoi Git n'utilise pas beaucoup de tag. Dans ClearCase, nous baseline/tag la branche de développement sur chaque build, et nous pouvons utiliser baseline/tag pour identifier une version, pas besoin de créer une branche pour la publication. Avec baseline/tag, nous pouvons toujours prendre une ligne de base/balise précédente à libérer, pas besoin de revenir en arrière.

Answer 1

je répondrai à vos premières 2 questions Selon cette ligne dans le arcticle

la branche de libération est fusionné dans maître (puisque chaque COMMIT maître est une nouvelle version par définition, rappelez-vous)

Je dirais que vous devez libérer votre code à la production de maître

en ce qui concerne rollbacks d'enlever un élément mis en œuvre précédemment Je ne pense pas que ce soit correct puisque vous voulez l'histoire de ce code. vous devriez simplement supprimer le code obsolète faire un nouveau commit.

Answer 2

Disclaimer: réponses selon ma compréhension du flux git, donc ils ne peuvent pas être correct :)

1. From where do we release the code to production? The release/hotfix branch or the master? 

de l'article:

Par conséquent, chaque fois que des changements sont refusionnés en maître, c'est une nouvelle version de production par définition.

-> Communiqués de production de maître

2. Need to rollback in release branch, if some features in the current 
release branch are no longer required. 

Vous ne faites pas caractéristiques dans la branche de sortie, vous faites fonctionnalités dans les branches fonctionnelles. Dans une branche de publication, vous ne faites que des modifications mineures/corrections de bogues ou mettez à jour les métadonnées avant une version. Si ces changements sont redondants, il est probablement bon de restaurer la branche, car ce sont des changements mineurs de toute façon et probablement pas importants.

également de l'article:

Ajout de grandes nouvelles fonctionnalités ici est strictement interdite.Ils doivent être fusionnés en développement, et donc attendre la prochaine grande version.

3. If there is no change in the release branch, why do we even need one? I am from the ClearCase world, and I always have this impression that a branch is not required if there is no change on it. 

S'il n'y a pas de changements que vous avez raison, la branche est probablement redondante. Mais je pense que dans votre code vous avez le numéro de version quelque part? Cela devrait être mis à jour dans la branche de publication.

de l'article:

De plus, ils permettent de corrections de bugs mineurs et la préparation de méta-données pour une version (numéro de version, construire dates, etc.).

Edit:

4. Why Git is not using tag a lot. In ClearCase, we baseline/tag the development branch on every build, and we can use baseline/tag to identify a release, no need to create a branch for release. With baseline/tag, we can always take a previous baseline/tag to release, no need to rollback. 

Vous ne devez pas utiliser le nouveau allouent développer de commencer une branche de sortie.