Stratégie de branche Git pour une petite équipe de développement [fermé]

Nous avons une application Web que nous mettons à jour et publions presque quotidiennement. Nous utilisons git comme notre VCS, et notre stratégie de branchement actuelle est très simple et brisée: nous avons une branche principale et nous vérifions les changements qui nous «sentent bien» dedans. Cela fonctionne, mais seulement jusqu'à ce que nous enregistrions un changement de rupture.

Quelqu'un a-t-il une stratégie de branche git préférée pour les petites équipes qui répond aux exigences suivantes:

1. Fonctionne bien pour les équipes de 2 à 3 développeurs
2. Léger et pas trop de processus
3. Permet aux développeurs d'isoler facilement le travail sur les corrections de bogues et les fonctionnalités plus importantes
4. Nous permet de garder une branche stable (pour ces moments `` oh 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

Vous pourriez bénéficier du flux de travail décrit par Scott Chacon dans Pro Git . Dans ce flux de travail, vous avez deux branches qui existent toujours, maîtriser et développer .

master représente la version la plus stable de votre projet et vous ne déployez en production qu'à partir de cette branche.

develop contient des changements en cours et qui ne sont pas nécessairement prêts pour la production.

À partir de la branche de développement , vous créez des branches de rubrique pour travailler sur des fonctionnalités et des correctifs individuels. Une fois que votre fonctionnalité / correctif est prêt à être utilisé, vous le fusionnez dans le développement , à quel point vous pouvez tester comment il interagit avec d'autres branches de sujet dans lesquelles vos collègues ont fusionné. Une fois que le développement est dans un état stable, fusionnez-le dans master . Le déploiement en production à partir du maître doit toujours être sûr .

Scott décrit ces branches de longue date comme des "silos" de code, où le code d'une branche moins stable finira par "passer" à une branche considérée comme plus stable après les tests et l'approbation générale par votre équipe.

Étape par étape, votre flux de travail sous ce modèle pourrait ressembler à ceci:

1. Vous devez corriger un bogue.
2. Créez une branche appelée myfix basée sur la branche de développement .
3. Travaillez sur le bogue dans cette branche de rubrique jusqu'à ce qu'il soit corrigé.
4. Fusionner myfix dans develop . Exécutez des tests.
5. Vous découvrez que votre correctif est en conflit avec une autre branche de sujet hisfix que votre collègue a fusionnée dans develop pendant que vous travailliez sur votre correctif.
6. Apportez plus de modifications dans la branche myfix pour gérer ces conflits.
7. Fusionnez myfix dans le développement et réexécutez les tests.
8. Tout fonctionne bien. Fusionner développer en maître .
9. Déployez-le en production à partir du master à tout moment, car vous savez qu'il est stable.

Pour plus de détails sur ce flux de travail, consultez le chapitre Flux de travail de branchement dans Pro Git.

Après être arrivé en tant que novice en essayant de trouver une stratégie simple pour enseigner à d'autres développeurs qui n'ont jamais utilisé le contrôle de code source. C'est celui qui convient à http://nvie.com/posts/a-successful-git-branching-model/ J'ai essayé d'utiliser le flux de travail GIT standard qui se trouve dans les pages de manuel, mais cela m'a légèrement confus et mon public complètement.

Au cours des 6 derniers mois, je n'ai eu à résoudre les conflits que deux fois. J'ai ajouté des étapes pour toujours tester après une fusion et pour «récupérer et fusionner» ou «tirer - rebase» 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.

(J'ai fait mon commentaire ci-dessus, c'est sa propre réponse, comme j'aurais dû au départ.)

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 de master nommée de manière descriptive (par exemple: new-oauth2-scopes)
• Engagez-vous dans cette branche localement et transférez régulièrement 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 pour la fusion, ouvrez une pull request
• Une fois que quelqu'un d'autre a examiné et approuvé la fonctionnalité, vous pouvez la fusionner dans la version principale
• Une fois qu'il est fusionné et poussé vers `` maître '', vous pouvez et devez déployer immédiatement

Voir l'article entier pour plus de détails: http://scottchacon.com/2011/08/31/github-flow.html

Notez que les "pull requests" sont une invention de Github, et c'est quelque chose qui est intégré à leur site Web, pas à Git lui-même: https://help.github.com/articles/using-pull-requests/

Utilisez la masterbranche comme branche de développement et créez des branches de version pour effectuer des corrections de bogues.

Toutes les nouvelles fonctionnalités continueront masterpendant la fenêtre de développement (soit validées directement, soit sous forme de branches de sujet avec des pull-requests, à vous - non montrées dans le graphique). Une fois que toutes vos fonctionnalités planifiées sont implémentées, entrez le gel des fonctionnalités et effectuez des tests. Lorsque vous êtes satisfait, marquez la sortie mastercomme v1.0.

Au fil du temps, vos utilisateurs trouveront des bogues v1.0, vous voudrez donc créer une branche à partir de cette balise (par exemple, nommez-la après la publication 1.0) et corrigez ces bogues dans la branche. Lorsque vous avez suffisamment de bogues corrigés pour que vous pensiez que cela justifie une nouvelle version, marquez-le comme v1.0.1et fusionnez-le à nouveau master.

Pendant ce temps, une nouvelle fenêtre de développement peut se produire sur la masterbranche qui sera éventuellement étiquetée v1.1.

Rincer et répéter.

Cela suit la logique de numérotation de version sémantique .

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

Dans un VCS, avoir juste une branche "maître" 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 succursale .

Mais dans un DVCS (comme dans un VCS «décentralisé»), vous avez également un problème de publication , avec des branches que vous gardez locales dans vos référentiels et des branches vers lesquelles vous poussez ou que vous extrayez .

Dans ce contexte, commencez par identifier votre effort de développement simultané et décidez d'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 pourrait en tirer profit pour:
  • rebase son développement actuel par-dessus (pour les tests locaux, ou pour intégrer sur le repo de développement local un correctif réalisé dans le repo prod sur la branche prod)
  • branche pour faire de nouvelles fonctionnalités (à partir d'un code stable connu)
  • branche pour démarrer la branche de version suivante (celle qui doit être en production)
    personne ne doit pousser directement vers prod (d'où la lecture seule)
• release est une branche de consolidation en lecture-écriture, où les commits pertinents sont sélectionnés pour faire partie de la prochaine version.
  Tout le monde peut pousser pour mettre à jour la prochaine version.
  Tout le monde peut tirer de ladite 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 poussée vers le repo prod central), et peut être poussée / extraite entre les dépôts de développement. Il représente un effort à moyen et long terme, différent du développement quotidien
• master représente le développement actuel et est poussé / tiré entre les dépôts de développement.

D'autres processus de gestion des versions existent, comme l' atteste cette question SO .

Lisez les équipes Git Workflow for Agile de ReinH 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 entre dans une branche quelconque. Revenez au maître uniquement lorsque vous êtes prêt à ce que tous les utilisateurs travaillant en dehors de la branche de fonctionnalités puissent l'utiliser.

Remarque: cette stratégie n'est guère spécifique à git, mais git facilite la mise en œuvre de cette stratégie.