Stratégie de branche Git pour une petite équipe de développement
Nous avons une application Web que nous mettons à jour et publions presque quotidiennement. Nous utilisons git en tant que notre VCS, et notre stratégie de création de branche actuelle est très simple et erronée: nous avons une branche principale et nous vérifions les modifications pour lesquelles nous nous sentons bien. Cela fonctionne, mais seulement jusqu'à ce que nous vérifions un changement radical.
Quelqu'un a-t-il une stratégie de branche préférée de Git pour petites équipes qui répond aux exigences suivantes:
- Fonctionne bien pour des équipes de 2 à 3 développeurs
- Léger et pas trop de processus
- Permet aux développeurs d'isoler le travail sur les corrections de bugs et les fonctionnalités plus importantes en toute simplicité
- Nous permet de garder une branche stable (pour les moments de "merde" où nous devons faire fonctionner nos serveurs de production)
Idéalement, j'aimerais voir votre processus étape par étape pour un développeur travaillant sur un nouveau bogue.
Scott Chacon décrit dans Pro Git . Dans ce flux de travail, vous avez toujours deux branches, maître et développez .
master représente la version la plus stable de votre projet et vous ne déployez en production que depuis cette branche.
develop contient des modifications en cours qui ne sont pas nécessairement prêtes pour la production.
À partir de la branche develop , vous créez des branches de sujet pour travailler sur des fonctionnalités et des correctifs individuels. Une fois que votre fonctionnalité/solution est prête à fonctionner, vous la fusionnez en develop . Vous pouvez alors tester son interaction avec d'autres branches de sujet que vos collègues ont fusionné. Une fois développé dans un état stable, fusionnez-le en maître . Le déploiement en production à partir de maître doit toujours être sûr.
Scott décrit ces branches de longue date comme des "silos" de code, dans lesquels le code d'une branche moins stable finira par "passer" à une classe considérée comme plus stable après des tests et l'approbation générale de votre équipe.
Étape par étape, votre flux de travail sous ce modèle pourrait ressembler à ceci:
- Vous devez corriger un bogue.
- Créez une branche appelée myfix basée sur la branche develop .
- Travaillez sur le bogue dans cette branche de sujet jusqu'à ce qu'il soit corrigé.
- Fusionner myfix en développer . Exécuter des tests.
- Vous découvrez que vos correctifs sont en conflit avec une autre branche de sujet hisfix dans laquelle votre collègue a fusionné développer pendant que vous travailliez sur votre solution.
- Apportez plus de modifications à la branche myfix pour résoudre ces conflits.
- Fusionnez myfix en développez et exécutez à nouveau les tests.
- Tout fonctionne bien. Fusionner développer en maître .
- Déployez en production à partir de maître à tout moment, car vous savez qu'il est stable.
Pour plus de détails sur ce workflow, consultez le chapitre Branching Workflows de Pro Git.
Après être arrivé en tant que novice, essayez de trouver une stratégie simple pour enseigner à d’autres développeurs qui n’ont jamais utilisé le contrôle de source. C’est celui qui convient http://nvie.com/posts/a-successful-git-branching-model/ J’ai essayé d’utiliser le flux de travail standard de GIT dans les pages de manuel, mais cela m’a un peu dérouté et mon public complètement.
Au cours des 6 derniers mois, je n'ai eu à résoudre que deux fois les conflits. J'ai ajouté des étapes pour toujours tester après une fusion et pour "chercher et fusionner" ou "tirer - resserrer" beaucoup (une fois le matin et l'après-midi) tout en développant des fonctionnalités. Nous avons également utilisé github.com comme emplacement central pour extraire le dernier code.
(Fait mon commentaire ci-dessus c'est sa propre réponse, comme j'aurais dû initialement.)
De Scott Chacon de Github:
Comment nous le faisons Alors, qu'est-ce que GitHub Flow?
- Tout ce qui se trouve dans la branche principale est déployable
- Pour travailler sur quelque chose de nouveau, créez une branche nommée de façon descriptive à partir du maître (par exemple: new-oauth2-scopes)
- S'engager dans cette branche localement et régulièrement Poussez votre travail vers la même branche nommée sur le serveur
- Lorsque vous avez besoin de commentaires ou d'aide, ou que vous pensez que la branche est prête à être fusionnée, ouvrez une demande d'extraction .
- Une fois la fonctionnalité vérifiée et validée par une autre personne, vous pouvez la fusionner en une version principale.
- Une fois fusionné et poussé sur ‘maître’, vous pouvez et devez déployer immédiatement
Voir l'article complet pour plus de détails: http://scottchacon.com/2011/08/31/github-flow.html
Notez que les "demandes d'extraction" sont une invention de Github, et c'est quelque chose qui est intégré dans leur site Web, pas à Git lui-même: https://help.github.com/articles/using-pull-requests/
Utilisez la branche master comme branche de développement et créez des branches de version pour résoudre les bogues.
Toutes les nouvelles fonctionnalités iront sur master pendant la fenêtre de développement (engagées directement ou sous forme de branches de sujet avec demandes d'extraction, à vous de choisir - n'apparaissent pas dans le graphique). Une fois que toutes les fonctionnalités planifiées sont implémentées, entrez dans le gel des fonctionnalités et effectuez des tests. Quand vous êtes content, marquez le communiqué sur master comme v1.0.
Au fil du temps, vos utilisateurs trouveront des bogues dans v1.0 donc vous voudrez créer une branche à partir de cette balise (par exemple, nommez-la après la publication 1.0) et corrigez ces bugs dans la branche. Lorsque vous avez suffisamment corrigé de bugs pour justifier une nouvelle version, identifiez-le comme suit: v1.0.1 et le fusionner dans master.
En attendant, une nouvelle fenêtre de développement peut se produire sur la branche master qui sera éventuellement étiquetée comme v1.1.
Rincer et répéter.
Ceci suit Versioning Semantic logique de numérotation.
---------(v1.0)--------------------------------(v1.1)-----------------------------> master
\ \
---(v1.0.1)---(v1.0.2)---> 1.0 ---(v1.1.1)---(v1.1.2)---> 1.1
Dans un VCS, le simple fait de créer une branche "principale" montre rapidement ses limites, car vous ne pouvez pas poursuivre tous les efforts de développement en même temps sur une branche.
Cela signifie que vous devez savoir quand créer une branche.
Mais dans un DVCS (comme dans un VCS "décentralisé"), vous avez également un numéro de publication, avec des branches que vous gardez local vers vos référentiels et les branches sur lesquelles vous poussez ou tirez.
Dans ce contexte, commencez par identifier vos efforts de développement simultanés et choisissez un processus de publication (Push/Pull). Par exemple (et ce n'est pas le seul moyen):
- prod est une branche publique en lecture seule avec le code en production. Tout le monde pouvait en tirer pour:
- redéfinir le développement en cours sur celui-ci (pour les tests locaux ou pour l'intégration dans le référentiel de développeurs local d'un correctif fourni dans le référentiel de produits de la branche prod)
- branche pour faire de nouvelles fonctionnalités (à partir d'un code stable connu)
- branche pour démarrer la prochaine branche de publication (celle qui doit être en production)
personne ne devrait pousser directement à prod (d'où la lecture seule)
- release est une branche de consolidation en lecture-écriture, dans laquelle les commits pertinents sont sélectionnés pour faire partie de la prochaine version.
Tout le monde peut appuyer sur Libérer pour mettre à jour la prochaine version.
Chacun peut retirer de cette version afin de mettre à jour son processus de consolidation local. - featureX est une branche privée en lecture-écriture (en ce sens qu’elle n’a pas besoin d’être Push pour le dépôt central de prod), et peut être poussée/tirée entre les dépôts de dev. Il représente un effort à moyen et long terme, différent du développement quotidien
- master représente le dev actuel et est poussé/tiré entre les dev dev.
Il existe d’autres processus de gestion des versions, comme ceci La question SO atteste .
Lisez le flux de travail Git pour Rein de ReinH dans les équipes ici: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
Cela fonctionne très bien pour les petites équipes. Le but ici est de s’assurer que tout ce qui pourrait être potentiellement instable va dans une branche quelconque. Ne fusionnez à nouveau que lorsque vous êtes prêt à être utilisé par toutes les personnes travaillant en dehors de la branche de fonctionnalité.
Remarque: cette stratégie n’est guère spécifique à Git, mais git rend sa mise en œuvre assez facile.