Stratégie de twig Git pour la petite équipe de développement

Nous avons une application Web que nous mettons à jour et publions presque quotidiennement. Nous utilisons git comme VCS, et notre stratégie de twigment actuelle est très simple et brisée: nous avons une twig principale et nous vérifions les changements auxquels nous nous sentons bien. Cela fonctionne, mais seulement jusqu’à ce que nous vérifions un changement de rupture.

Est-ce que quelqu’un a une stratégie de twig préférée pour les petites équipes qui répond aux exigences suivantes:

  1. Fonctionne bien pour des é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 correctifs de bogues et les fonctionnalités plus importantes
  4. Nous permet de garder une twig stable (pour les moments 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 tirer parti du workflow décrit par Scott Chacon dans Pro Git . Dans ce workflow, vous avez deux twigs qui existent toujours, maîsortingsent et développent .

master représente la version la plus stable de votre projet et vous ne le déployez que dans cette twig.

développer contient des modifications en cours et peut ne pas être nécessairement prêt pour la production.

A partir de la twig de développement , vous créez des twigs de sujet pour travailler sur des fonctionnalités et des correctifs individuels. Une fois que votre fonctionnalité / correctif est prêt à être utilisé, vous le fusionnez en développement , à quel point vous pouvez tester son interaction avec d’autres twigs de sujet dans lesquelles vos collègues ont fusionné. Une fois développé , fusionnez-le en master . Il devrait toujours pouvoir être déployé en toute sécurité dans la production à partir de master .

Scott décrit ces twigs de longue durée comme des “silos” de code, où le code dans une twig moins stable finira par “devenir” plus stable après un test et une approbation générale par votre équipe.

Pas à pas, votre workflow sous ce modèle pourrait ressembler à ceci:

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

Pour plus de détails sur ce stream de travail, consultez le chapitre Branchement des stream de travail dans Pro Git.

Après être entré en tant que novice, il a essayé 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 le mieux à http://nvie.com/posts/a-successful-git-branching-model/ J’ai essayé d’utiliser le workflow GIT standard qui se trouve dans les pages de manuel, mais cela m’a un peu déconcerté et complètement perdu mon public.

Au cours des six 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 “aller chercher et fusionner” ou “tirer” -base “beaucoup (une fois le matin et l’après-midi) tout en développant des fonctionnalités. Nous avons également utilisé github.com comme endroit central pour obtenir le dernier code.

(Fait mon commentaire au-dessus de sa propre réponse, comme je devrais l’avoir initialement.)

De Scott Chacon de Github:

Comment nous le faisons donc, qu’est-ce que GitHub Flow?

  • Tout ce qui se trouve dans la twig principale est déployable
  • Pour travailler sur quelque chose de nouveau, créez une twig nommément nommée à partir de master (ex: new-oauth2-scopes)
  • S’engager localement dans cette twig et pousser régulièrement votre travail sur la même twig nommée sur le serveur
  • Lorsque vous avez besoin de commentaires ou d’aide, ou que vous pensez que la succursale est prête à fusionner, ouvrez une requête d’extraction.
  • Une fois que quelqu’un a passé en revue et signé la fonctionnalité, vous pouvez la fusionner en master
  • Une fois fusionné et poussé à «maîsortingser», vous pouvez et devez déployer immédiatement

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

Notez que les “demandes de tirage” sont une invention de Github, et que 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 twig principale comme twig de développement et créez des twigs de publication pour effectuer des corrections de bogues.

Toutes les nouvelles fonctionnalités seront master lors de la fenêtre de développement (soit validées directement, soit en tant que twigs de sujet avec des requêtes pull, jusqu’à vous – non affichées dans le graphique). Une fois toutes les fonctionnalités planifiées mises en œuvre, entrez le gel des fonctionnalités et effectuez des tests. Lorsque vous êtes heureux, marquez la version sur master comme v1.0 .

Au fil du temps, vos utilisateurs trouveront des bogues dans la version v1.0 , vous devrez donc créer une twig à partir de cette balise (par exemple, la nommer après la version 1.0 ) et corriger ces bogues dans la twig. Lorsque vous avez suffisamment de bogues corrigés, vous pensez qu’il mérite une nouvelle version, puis le v1.0.1 en v1.0.1 et le fusionne en master .

En attendant, une nouvelle fenêtre de développement peut se produire sur la twig principale qui sera éventuellement étiquetée comme v1.1 .

Rincer et répéter

Cela suit la logique de numérotation du contrôle 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 twig “master” montre rapidement ses limites car vous ne pouvez pas poursuivre tous les efforts de développement en même temps sur une twig.
Cela signifie que vous devez savoir quand twigr .

Mais dans un DVCS (comme dans VCS “décentralisé”), vous avez également un problème de publication , avec des twigs que vous conservez localement dans vos référentiels et des twigs vers lesquelles vous passez ou tirez.

Dans ce contexte, commencez par identifier votre effort de développement simultané et choisissez un processus de publication (push / pull). Par exemple (et ce n’est pas la seule façon):

  • prod est une twig publique en lecture seule avec le code en production. Tout le monde pourrait en tirer pour:
    • rebase son développement actuel (pour les tests locaux, ou pour l’intégration sur le serveur local, un correctif fait dans le rep repo sur la twig prod)
    • twig pour faire de nouvelles fonctionnalités (à partir d’un code stable connu)
    • twig pour lancer la prochaine twig de publication (celle qui doit être en production)
      personne ne devrait pousser directement pour prod (d’où la lecture seule)
  • release est une twig de consolidation en lecture-écriture où les validations pertinentes sont sélectionnées pour faire partie de la prochaine version.
    Tout le monde peut pousser pour mettre à jour la prochaine version.
    Tout le monde peut tirer de cette version pour mettre à jour son processus de consolidation local.
  • featureX est une twig de lecture-écriture privée (dans la mesure où il n’a pas besoin d’être transféré vers le référentiel central), et peut être poussé / tiré entre les repositorys de développement. Il représente un effort à moyen et à long terme, différent du dev quotidien
  • master représente le dev actuel et est poussé / tiré entre les rep repos.

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

Lisez le Git Workflow pour les équipes 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 twig quelconque. Ne fusionnez à nouveau sur master que lorsque vous êtes prêt à être utilisé par tous ceux qui travaillent en dehors de la twig.

Note: cette stratégie est peu spécifique, mais git facilite l’implémentation de cette stratégie.