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

Question

Nous avons une application web que nous mettons à jour et publions presque quotidiennement. Nous utilisons git comme VCS, et notre stratégie de branchement actuelle est très simple et cassée : nous avons une branche principale et nous y enregistrons les changements qui nous conviennent. Cela fonctionne, mais seulement jusqu'à ce que nous y insérions un changement de rupture.

Est-ce que quelqu'un a une stratégie de branche git préférée pour 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. Cela nous permet de conserver une branche 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 bug.

Answer 1

Vous pourriez bénéficier du flux de travail que Scott Chacon décrit dans Pro Git . Dans ce flux de travail, vous avez deux branches qui existent toujours, maestro y développer .

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

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

De la développer vous créez des branches thématiques pour travailler sur des fonctionnalités et des corrections individuelles. Une fois que votre fonctionnalité/correction est prête, vous la fusionnez dans la branche développer Vous pouvez alors tester son interaction avec d'autres branches de thèmes que vos collègues ont fusionnées. Une fois que développer est dans un état stable, fusionnez-le dans maestro . Il devrait toujours être sûr de déployer en production à partir de maestro .

Scott décrit ces branches de longue durée 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 avoir été testé et approuvé par votre équipe.

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

1. Vous devez corriger un bug.
2. Créez une branche appelée myfix qui est basé sur le développer branche.
3. Travailler sur le bogue dans cette branche du sujet jusqu'à ce qu'il soit corrigé.
4. Fusionner myfix en développer . Exécutez les tests.
5. Vous découvrez que votre correction entre en conflit avec une autre branche du sujet hisfix que votre collègue a fusionné avec développer pendant que tu travaillais sur ta réparation.
6. Effectuez d'autres changements dans le myfix pour faire face à ces conflits.
7. Fusionner myfix en développer et refaire des tests.
8. Tout fonctionne bien. Fusionner développer en maestro .
9. Déployer en production à partir de maestro à tout moment, parce que vous savez que c'est stable.

Pour plus de détails sur ce flux de travail, consultez la page Flux de travail en dérivation dans le chapitre Pro Git.

Answer 2

Après être arrivé en tant que novice, j'ai essayé de trouver une stratégie simple à enseigner à d'autres développeurs qui n'ont jamais utilisé le contrôle de source. C'est celle qui correspondait http://nvie.com/posts/a-successful-git-branching-model/ J'ai essayé d'utiliser le flux de travail standard de GIT qui se trouve dans les pages de manuel, mais cela m'a un peu désorienté, ainsi que mon public.

Au cours des six derniers mois, je n'ai dû régler 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" souvent (une fois le matin et l'après-midi) pendant le développement des fonctionnalités. Nous avons également utilisé github.com comme endroit central pour tirer le dernier code.

Answer 3

(J'ai fait mon commentaire au-dessus de sa propre réponse, comme j'aurais dû le faire 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 master est déployable
• Pour travailler sur quelque chose de nouveau, créez une branche portant un nom descriptif à partir de master (par ex : nouveau-oauth2-scopes)
• S'engager sur cette branche localement et pousser régulièrement votre travail vers la même branche nommée sur le serveur.
• Lorsque vous avez besoin d'un retour ou d'aide, ou que vous pensez que la branche est prête à être fusionnée, ouvrez une demande de retrait
• Après que quelqu'un d'autre ait revu et signé la fonctionnalité fonctionnalité, vous pouvez la fusionner dans master
• Une fois qu'il est fusionné et poussé vers 'master', 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 "pull requests" sont une invention de Github, et que c'est quelque chose qui est intégré dans leur site web, et non dans Git lui-même : https://help.github.com/articles/using-pull-requests/

Answer 4

Utilisez le master comme branche de développement. Toutes les nouvelles fonctionnalités y sont placées pendant la fenêtre de développement. Lorsque vous avez terminé l'implémentation de vos nouvelles fonctionnalités (c'est-à-dire le gel des fonctionnalités), créez une nouvelle branche à partir de master avec la version de publication (par ex. 1.0 ). Faites-y vos tests et votre travail de candidat à la publication. À partir de ce moment-là sólo apporter des corrections de bogues à votre 1.0 branche. Lorsque vous en êtes satisfait, marquez-la en tant que v1.0 . Fusionner les 1.0 dans master (non montré). Au fil du temps, vos utilisateurs trouveront des bogues dans v1.0 vous devrez donc les corriger dans le fichier 1.0 branche. Lorsque vous avez corrigé suffisamment de bogues pour justifier une nouvelle version, marquez-la en tant que v1.0.1 . Pendant ce temps, le 1.1 la fenêtre de développement se passait sur le master branche. Rincer et répéter.

Cela suit Versionnage sémantique logique de numérotation.

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

Answer 5

Dans un VCS, le fait de n'avoir qu'une branche "master" montre rapidement ses limites car on ne peut pas poursuivre tout l'effort de développement en même temps sur une seule branche.
Cela signifie que vous devez savoir quand faire une branche .

Mais dans un DVCS (comme dans "Decentralized" VCS), vous avez aussi une numéro de publication avec les branches que vous conservez localement dans vos dépôts, et les branches vers lesquelles vous poussez ou dont vous tirez.

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 la seule façon) :

• prod est une branche publique en lecture seule avec le code en production. Tout le monde peut s'en inspirer pour :
  • rebase son développement actuel dessus (pour les tests locaux, ou pour intégrer sur le repo dev local un correctif fait dans le repo prod sur la branche prod)
  • branche pour réaliser de nouvelles fonctionnalités (à partir d'un code stable connu)
  • branch pour démarrer la prochaine branche de la version (celle qui sera 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 sur release pour mettre à jour la prochaine version.
  Chacun peut s'inspirer de ce communiqué pour mettre à jour son processus de consolidation local.
• featureX est une branche privée en lecture-écriture (dans le sens où elle n'a pas besoin d'être poussée vers le dépôt central de production), et peut être poussée/tirée entre les dépôts de développement. Elle représente un effort à moyen et long terme, différent du travail de développement quotidien.
• master représente le dev actuel, et est poussé/tiré entre les dépôts de dev.

Il existe d'autres processus de gestion des versions, comme celui-ci La question de SO atteste .