Quels sont les avantages et les inconvénients de git-flow vs github-flow? [fermé]

125

Nous avons récemment commencé à utiliser GitLab.

En utilisant actuellement un workflow «centralisé».

Nous envisageons de passer au github-flow mais je veux m'en assurer.

Quels sont les avantages et les inconvénients de git-flow vs github-flow ?

Paul McKenzie
la source

Réponses:

133

Comme discuté dans l'épisode 17 de GitMinutes , par Nicholas Zakas dans son article sur "Les flux de travail GitHub à l'intérieur d'une entreprise ":

Git-flow est un processus de gestion des changements dans Git qui a été créé par Vincent Driessen et accompagné de quelques extensions Git pour gérer ce flux.
L'idée générale derrière le flux git est d'avoir plusieurs branches distinctes qui existent toujours, chacun pour un but différent: master, develop, feature, releaseet hotfix.
Le processus de développement de fonctionnalités ou de bogues passe d'une branche à une autre avant d'être finalement publié.

Certains des répondants ont indiqué qu'ils utilisent git-flowen général.
Certains ont commencé avec git-flowet s'en sont éloignés.

La principale raison de l'abandon est que le git-flowprocessus est difficile à gérer dans un modèle de déploiement continu (ou quasi-continu).
Le sentiment général est que cela git-flowfonctionne bien pour les produits dans un modèle de publication plus traditionnel, où les versions sont effectuées une fois toutes les quelques semaines, mais que ce processus se décompose considérablement lorsque vous sortez une fois par jour ou plus .

En bref:

Commencez avec un modèle aussi simple que possible (comme le flux GitHub a tendance à l'être), et passez à un modèle plus complexe si vous en avez besoin.


Vous pouvez voir une illustration intéressante d'un flux de travail simple , basé sur GitHub-Flow à l' adresse :
" Un simple modèle de branchement git ", les principaux éléments étant:

  1. master doit toujours être déployable.
  2. toutes les modifications apportées via les branches de fonctionnalités (pull-request + merge)
  3. rebase pour éviter / résoudre les conflits; fusionner enmaster

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682f666c6f77392f736b697463682f666c6f77392d323303323303363323303323303323303323323323323323303323303323303323323303323323303303303323303303303303303303323303303303303303 et


Pour un flux de travail plus complet et plus robuste, consultez gitworkflow (un mot) .

VonC
la source
88

Il n'y a pas de workflow miracle où tout le monde devrait suivre, car tous les modèles sont sous-optimaux. Cela dit, vous pouvez sélectionner le modèle approprié pour votre logiciel en fonction des points ci-dessous;

Plusieurs versions en production - utilisez Git-flow

Si votre code a plusieurs versions en production (c'est-à-dire des produits logiciels typiques comme les systèmes d'exploitation, les packages Office, les applications personnalisées, etc.), vous pouvez utiliser git-flow. La raison principale est que vous devez continuellement prendre en charge les versions précédentes en production tout en développant la version suivante.

Version unique en production logiciel simple - utilisez Github-flow

Si votre code n'a qu'une seule version en production à tout moment (c.-à-d. Sites Web, services Web, etc.), vous pouvez utiliser github-flow. La raison principale est que vous n'avez pas besoin de compliquer les choses pour le développeur. Une fois que le développeur a terminé une fonctionnalité ou terminé un correctif, il est immédiatement promu en version de production.

Version unique en production mais logiciel très complexe - utilisez Gitlab-flow

De gros logiciels comme Facebook et Gmail, vous devrez peut-être introduire des branches de déploiement entre votre succursale et votre succursale principale où les outils CI / CD> pourraient s'exécuter, avant d'entrer en production. L'idée est d'introduire plus de protection dans la version de production car elle est utilisée par des millions de personnes.

Gayan Pathirage
la source
7
Il suffit d'ajouter "Gitdmz-flow" / "Git DMZ Flow" à la liste: gist.github.com/djspiewak/9f2f91085607a4859a66
Robert Fey
1
Les entreprises référencées utilisent un système basé sur le tronc. paulhammant.com/2014/01/08/…
PatrickWalker
1
Le flux Git DMZ est plus similaire à Gitflow et la branche DMZ est comme développer la branche. Par conséquent, je ne ressens rien de spécial à ce sujet.
Gayan Pathirage
2
D'après ce que je comprends, Git-Flow ne fonctionne pas bien avec la version multi-production. La stratégie de correctif logiciel suppose que vous disposez d'une seule version de production et que vous effectuez un correctif sur la branche de version correspondante (et que vous la fusionnez ultérieurement pour développer la branche). Il semble ne pas répondre à la façon dont vous pouvez corriger un bogue qui existe dans plusieurs branches de production.
Adrian Shum
5
@GayanPathirage En fait, ce n'est pas le cas. 1. Balises GitFlow "classiques" chez le maître. La branche Hotfix vous permet uniquement de corriger la dernière version de production (du maître). 2. «branche de version» signifie autre chose dans Gitflow, qui est en fait la branche de prévisualisation de la pré-version (branchée à partir de la branche de développement, et visant à fusionner avec master quand elle est vraiment publiée). 3. Ce que vous faites référence est quelque chose appelé "branche de support" dans GitFlow (c'est une des raisons pour lesquelles je n'aime pas GitFlow: la terminologie non conventionnelle). Cependant, il s'agit toujours d'un flux expérimental (vous ne le voyez donc pas dans la plupart des intros Gitflow)
Adrian Shum
38

J'utilise le modèle git-flow depuis plus d'un an et c'est ok.

Mais cela dépend vraiment de la manière dont votre application sera développée et déployée.

Cela fonctionne bien lorsque vous avez une application dont le flux de développement / déploiement est lent.

Mais par exemple, comme GitHub nous avons une application qui a un flux de développement / déploiement rapide, nous déployons tous les jours, et parfois plusieurs fois par jour, dans ce cas, git-flow a tendance à tout ralentir à mon avis, et j'utilise GitHub couler.

L'autre chose à considérer est que git-flow n'est pas git standard, donc vous pourriez, et quand je dis que vous pourriez, je veux vraiment dire, vous trouverez des développeurs qui ne le savent pas, et puis il y a la courbe d'apprentissage, plus chance de gâcher les choses. De plus, comme mentionné ci-dessus, quelqu'un a développé un ensemble de scripts pour rendre l'utilisation de git-flow plus facile, vous n'avez donc pas à vous souvenir de toutes les commandes, cela vous aidera avec les commandes, mais vous rappeler le flux réel est votre travail , Je suis tombé sur plus d'une fois quand un développeur ne savait pas s'il s'agissait d'un correctif ou d'une fonctionnalité, ou même pire quand il ne se souvenait pas du flux et faisait des choses.

Il existe au moins une interface graphique prenant en charge git-flow pour Mac et Windows SourceTree .

Ces jours-ci, je penche davantage vers le flux GitHub, en raison de sa simplicité et de sa facilité de gestion. De plus, en raison du "déploiement précoce, souvent"

J'espère que cela t'aides

Diego Antunes
la source
+1. Je suis d'accord avec toi.
VonC le
2
Le flux GitHub se trouve dans Git-Flow. Pensez si vous avez besoin d'une intégration continue et d'un déploiement continu, vous pouvez simplement en exécuter autant que possible avec develop branch. Chaque fonctionnalité est dérivée de la branche de développement. Vous n'aurez peut-être pas besoin de la branche principale ou des branches d'édition, sauf si vous disposez de modèles de déploiement complexes. (Par exemple, votre version 1.1 est en direct sur un client, votre 1.2 est en direct sur un autre client et actuellement vous développez 1.3 pour votre nouveau client) Les 3 clients demanderont des corrections de bogues et des changements sur leur version respective.
Gayan Pathirage
Bonjour Diego et merci pour ta réponse. Qu'en est-il de la maintenance de plusieurs versions? Le faites-vous facilement avec Git Flow? J'ai entendu dire que c'était difficile car vous avez besoin de succursales de soutien! Pensez-vous que le modèle est bien adapté pour cela?
Luis Gouveia
1
Salut Luis, je pense que vous pouvez faire fonctionner le modèle, mais encore une fois, j'ai l'impression que vous pouvez obtenir la même chose avec un flux de travail git standard.
Diego Antunes
1
@LuisGouveia en fait, depuis votre question et ma réponse ci-dessus, je suis tombé sur un projet qui git-flow fonctionnera parfaitement, et je suis propriétaire du projet. L'idée est de l'utiliser git flow release...en combinaison avec des actions github pour déployer l'application. Dans ma réponse initiale, j'ai mentionné que nous avions publié plusieurs fois par jour, cela posait des problèmes lors de l'utilisation de git-flow. La raison pour laquelle je pense que git-flow fonctionnera bien dans ce projet est que nous avons un cycle de publication prédéfini, qui est l'un des principaux arguments de vente pour utiliser git-flow.
Diego Antunes