Quels sont les avantages et les inconvénients de git-flow par rapport à github-flow ?

Question

Nous avons récemment commencé à utiliser GitLab.

Nous utilisons actuellement un flux de travail "centralisé".

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

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

Answer 1

Comme discuté dans l'épisode 17 des GitMinutes, en Nicholas Zakas dans son article sur " Flux de travail GitHub au sein d'une entreprise " :

Git-flow est un processus de gestion des modifications 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 git-flow est d'avoir plusieurs branches séparées qui existent toujours, chacune pour un but différent : master , develop , feature , release et hotfix .
Le processus de développement de fonctionnalités ou de bogues passe d'une branche à l'autre avant d'être finalement publié.

Certains des répondants ont indiqué qu'ils utilisent git-flow en général.
Certains ont commencé par git-flow et s'en est éloigné.

La raison principale de ce déménagement est que le git-flow est difficile à gérer dans un modèle de déploiement continu (ou quasi-continu).
Le sentiment général est que git-flow fonctionne bien pour les produits dans un modèle de publication plus traditionnel, où les publications sont faites une fois toutes les quelques semaines, mais que ce processus s'effondre considérablement lorsque vous publiez une fois par jour ou plus. .

En bref :

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

---

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

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

Answer 2

Il n'existe pas de méthode de travail miracle que tout le monde devrait suivre, car tous les modèles sont sous-optimaux. Cela dit, vous pouvez choisir le modèle qui convient à votre logiciel en fonction des points ci-dessous ;

Versions multiples en production - utiliser Git-flow

Si votre code a plusieurs versions en production (c'est-à-dire les produits logiciels typiques tels que les systèmes d'exploitation, les progiciels de bureau, les logiciels de gestion de contenu, etc. produits logiciels typiques comme les systèmes d'exploitation, les progiciels de personnalisées, etc.), vous pouvez utiliser git-flow. La raison principale est que vous devez de supporter continuellement les versions précédentes en production tout en tout en développant la version suivante.

Version unique en production - logiciel simple à utiliser Github-flow

Si votre code n'a qu'une seule version en production à tout moment (i.e. sites web, services web, etc) vous pouvez utiliser github-flow. La raison principale de raison est que vous n'avez pas besoin de complexifier les choses pour le développeur. Une fois que le développeur a terminé une fonctionnalité ou une correction de bogue, elle est immédiatement immédiatement promu à la version de production.

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

Les grands logiciels tels que Facebook et Gmail, vous devrez peut-être introduire branches de déploiement entre votre branche et la branche maître où les outils de CI/CD > pourraient être exécutés, avant la mise en production. L'idée est de l'idée est d'introduire plus de protection à la version de production car elle est utilisée par millions de personnes.

Answer 3

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

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

Il fonctionne bien lorsque vous avez une application dont le 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 flow.

L'autre chose à prendre en compte est que git-flow n'est pas le git standard, donc vous pourriez, et quand je dis vous pourriez, je veux vraiment dire, vous trouverez des développeurs qui ne le connaissent pas, et alors il y a la courbe d'apprentissage, plus de chance de foirer 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, de sorte que vous n'avez pas à vous souvenir de toutes les commandes, il vous aidera avec les commandes, mais se souvenir du flux réel est votre travail, j'ai rencontré plus d'une fois un développeur qui ne savait pas s'il s'agissait d'un correctif ou d'une fonctionnalité, ou même pire quand ils ne peuvent pas se rappeler le flux et faire des choses.

Il existe au moins une interface graphique qui supporte git-flow pour Mac et Windows. SourceTree .

Ces jours-ci, je penche plutôt pour le flux GitHub, en raison de sa simplicité et de sa facilité de gestion. Aussi, à cause du "déployer tôt déployer souvent"...

J'espère que cela vous aidera