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

186

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

git branch git-branch Bilal et Olga
la source

Réponses:

247

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.

Jimmy Cuadra
la source
7
Aussi Scott Chacon a un excellent article sur son site sur la façon dont fonctionne le flux de travail avec Git de Github - scottchacon.com/2011/08/31/github-flow.html
program247365
71
Je pense que c'est génial, sauf si vous créez des branches de correction de bogue à partir de la branche de développement, vous ne pouvez pas la fusionner dans master et la déployer sans également fusionner dans tout le reste "nouveau" que vous n'avez pas encore publié, ce qui pourrait être une vraie douleur s'il y a quelque chose dans cette branche qui a besoin de documenter les changements de base de données ou autre chose difficile à faire. Je pense que pour les "hotfixes" urgents, vous devriez faire votre branche de master.
Richard
5
Et si nous développions 2 fonctionnalités distinctes, F1 et F2, où F1 doit être publié dans une semaine mais F2 doit être publié dans 2 semaines, en supposant que le développement de F1 et F2 coïncide? Des suggestions à ce sujet?
Murat Derya Özen
4
C'est developune «solution» inutile à un problème que git n'a pas. Pour autant que je sache, le succès est dû à un article bien rédigé, quoique mal orienté, sans commentaires autorisés. Voici un contre-article barro.github.io/2016/02
Tim Abell
5
À l'étape 8, fusionner la branche de développement en master semble être une mauvaise idée étant donné qu'une partie du code en développement n'est peut-être pas prête à entrer en production. Ne ferions-nous pas mieux de fusionner la branche de fonctionnalités dans master?
Todd
45

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.

Embrayage
la source
C'est un excellent lien! Ce flux de travail fonctionne à merveille pour notre petite équipe qui travaille toujours à distance et en parallèle sur plusieurs versions à la fois. Très bien documenté. Merci Clutch!
keithxm23
Ah, c'est là que j'ai trouvé ce lien :-) J'ai regardé plusieurs stratégies Git avant de mettre en place mon premier projet Git (je suis passé de SCCS à CVS à SVN au fil des ans et maintenant je voulais essayer Git pour un nouveau projet ) et c'est celui qui me semblait le plus logique. Je reconnais votre message, donc je suis presque sûr que c'est là que je l'ai trouvé. Alors merci - cela fonctionne à merveille!
Boise
4
Je meurs un peu à l'intérieur à chaque fois que je vois quelqu'un prendre ce billet de blog. Voici une réfutation: barro.github.io/2016/02
Tim Abell
Je partage le même sentiment avec vous @TimAbell; Je pense fortement que ce n'est pas bien quand le default master branchn'est PAS utilisé le plus souvent être développeur dans ce domaineA successful Git branching model
Nam G VU
35

(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/

programme247365
la source
4
Avec une équipe plus petite et des développeurs moins expérimentés avec git, la simplicité de ce flux de travail l'emporte. La seule chose que nous faisons différemment est d'avoir une branche «intermédiaire» entre la branche de fonctionnalité et le maître qui agit comme un site QA en direct pour que les non-développeurs acceptent la fonctionnalité dans un environnement de production.
Squadrons
@Squadrons sonne comme si vous aviez besoin de déployer Octopus pour cela, qui a des portes intégrées pour ok / nier les builds pour accéder à différents environnements et ne pollue pas votre contrôle de source avec de telles choses.
Tim Abell
Créer des branches de fonctionnalité hors du maître, puis les fusionner pour le déploiement est OK, tant que vous avez une balise pour qu'il y ait un point de restauration sûr. Les déploiements ne se déroulent pas toujours comme prévu. Que vous croyiez au "roll forward only" n'a pas beaucoup d'importance lorsque vous avez une hémorragie d'argent.
Razor
15

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
Leif Gruenwoldt
la source
5
N'oubliez pas de fusionner vos 1.0.1modifications dansmaster
kwahn
Et gardez toujours à l'esprit de rebaser 1.1le maître après la fusion 1.0.1- cela permet de minimiser les confictions.
Nam G VU
@NamGVU Je ne recommanderais pas cela. 1.1est une branche de version et possède des balises représentant l'état exact d'une ou plusieurs versions. Rebaser cette branche vous ferait perdre cette représentation. Je vous recommande fortement de définir vos branches de version pour refuser les poussées forcées pour éviter cela.
Leif Gruenwoldt
1
Non, ne fusionnez pas les branches de version avec master! Cela peut vous donner toutes sortes de maux de tête dont vous n'avez pas besoin (fusionner dans des éléments de version uniquement, fusionner des conflits avec des versions plus récentes, casser des versions, historique non linéaire, etc. Croyez-moi, je l'ai vu plus d'une fois) . Au lieu de cela, traitez les rejets comme des fourchettes. Voir bitsnbites.eu/a-stable-mainline-branching-model-for-git
m-bitsnbites
4
cherry-pick est une meilleure option pour récupérer les modifications de version dans master
BartoszKP
4

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 .

VonC
la source
3

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.

whaley
la source