Branchement et fusion des meilleures pratiques dans Git

Question

Nous avons une équipe de développeurs de 4 personnes et nous avons récemment déménagé à Git. Nous voulons connaître les meilleures pratiques concernant le flux de travail avec branchement et fusion.

Nous utilisons une version allégée de Git Flow. Nous avons une branche dev, staging et master qui sont toutes linéaires entre elles.

• la mise en scène est dérivée du maître
• dev est ramifié de la mise en scène

En plus de cela, nous utilisons des branches de fonctionnalités et de correctifs pour travailler sur de nouvelles fonctionnalités et corriger des bugs.

J'ai les questions suivantes:

1. Doit-on créer des branches de dev ou de master?
2. Lorsqu'une branche de fonctionnalité est prête, devons-nous fusionner la branche de fonctionnalité en dev, puis fusionner le dev dans le transfert, ou fusionner la branche de fonctionnalité en transfert et ensuite la branche de fonctionnalité en maître?

Je pense que nous devrions passer du master et fusionner la branche de fonctionnalité, car il pourrait y avoir quelque chose dans le développement que nous ne voudrions pas fusionner avec le staging et le master.

Quel est ton opinion? Quelles sont les meilleures pratiques?

Answer 1

Nous nous sommes installés sur un workflow appelé Git Flow , mais au lieu de ramifier les fonctionnalités de dev, nous les branchons à partir de la version actuelle. Cela nous permet de travailler sur des problèmes distincts à différentes vitesses. S'ils réussissent en QA, ils entrent dans la version.

Concernant les succursales et le déploiement:

• La branche dev est déployée automatiquement pour tester les serveurs.
• La branche de publication actuelle est déployée automatiquement sur les serveurs intermédiaires.
• La branche master est déployée manuellement sur les serveurs actifs par le release-master.

Le workflow est le suivant:

1. Créez une branche de version à partir de master au début de chaque version/sprint, par ex. version/2015-mai .
2. Créer une branche dev à partir de la version /2015-mai
3. Travailler sur une nouvelle fonctionnalité, branchez-vous à partir de la version et nommez-la fonctionnalité/ISSUE_NUMBER.
4. Travaillez sur votre fonctionnalité.
5. Lorsqu'il est prêt pour les tests, fusionnez-le dans dev.
6. S'il est accepté, fusionnez-le dans la branche de publication actuelle.
7. Si ce n'est pas accepté, passez à l'étape 4.
8. Lorsque la version est prête, fusionnez-la dans master

Une fois que la version a été déployée pour vivre et qu'un bogue critique est découvert, nous branchons une branche de correctif à partir du maître (par exemple, hotfix/ISSUE_NUMBER), fusionnez-le à nouveau dans le maître et déployez à nouveau.

Answer 2

Cela dépend toujours de la façon dont vous voulez travailler et de l'accord d'équipe. Cela dit.

1. Une fonction démarre de la branche dev dans sa propre branche. À partir de la branche principale, vous devez uniquement créer une branche hotfixes car la branche principale doit toujours être la version stable de votre logiciel.
2. Quand une branche de fonctionnalité est terminée, elle devrait être fusionnée en dev, puis à un moment donné, vous devriez ramifier votre prochaine version de dev (y compris certaines fonctionnalités) en une nouvelle branche 'release/*' qui sera fusionnée en master une fois stabilisée et bien testée.

Dans la page Atlassian vous avez une très belle explication de ce workflow

L'idée avec ce type de workflows est d'avoir une branche de version stable dans laquelle vous pouvez travailler et corriger tout bug immédiatement si vous en avez besoin avec suffisamment de confiance pour qu'il soit toujours stable et qu'aucune nouvelle fonctionnalité ou refactorisation ne se glisse sans s'en rendre compte.

Aussi pour avoir l'isolement et la liberté pour chaque nouvelle fonctionnalité qui sera développée dans sa propre branche sans aucun bruit provenant d'autres fonctionnalités. Enfin, vous fusionnerez vos fonctionnalités dans votre branche de développement et de là dans la branche principale pour la prochaine version.

La seule chose que je recommanderais pour vous est d'apprendre à rebaser vos branches de fonctionnalités au-dessus de la branche de développement chaque fois qu'une autre fonctionnalité est fusionnée en dev pour éviter de résoudre les conflits au moment de la fusion, mais isolément sur la branche de fonctionnalité où vous savez quoi vos changements le sont.

Il semble également que cette question ait déjà été posée

Answer 3

Bien que Git Flow soit un excellent modèle de branchement, les questions que vous posez sont le symptôme d'un problème plus important: Git Flow est trop lourd pour une petite équipe travaillant sur un produit Web grand public (je fais l'hypothèse que vous travaillez sur le Web grand public produit, n'hésitez pas à ignorer si vous codez la salle de contrôle de la centrale nucléaire).

Je vous encourage à envisager le déploiement continu (CD) avec un modèle de branchement extrêmement simple:

Il est très facile d'installer un CD de nos jours:

1. Utilisez Travis , CodeShip , Jenkins ou un système similaire pour exécuter une build complète et une suite de tests sur chaque commit poussé sur chaque branche de votre base de code
2. Configurez Travis/Codeship/Jenkins pour déployer en production chaque commit à master qui réussit les tests.
3. Créez une nouvelle branche à partir de master pour chaque nouvelle fonctionnalité.
4. Codez une nouvelle fonctionnalité et testez-la sur une branche.
5. Fusionnez une branche de fonctionnalité dans master et regardez-la en ligne.

Il y a beaucoup d'objections communes à cela, que tout peut être résumé comme "mais que faire si j'introduis un bug?!". La réponse est "Vous allez le réparer!". Si vous écrivez des tests, si vous surveillez votre site de production, si vous effectuez des révisions de code, si vous pratiquez la programmation par paires, si vous utilisez des indicateurs de fonctionnalité et si vous gardez vos fonctionnalités de petite taille, les avantages que vous obtenez du CD l'emportent sur les problèmes occasionnels n'importe quel jour.

Je vous encourage à essayer. Cela vous permettra de vous concentrer sur ce qui compte vraiment: créer un excellent produit! Si vous ne me croyez pas, jetez un œil à ceci excellente présentation de Github .