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

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 ?

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

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

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.

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