Quels sont les avantages et les inconvénients de git-flow vs github-flux?
3 réponses
Tel Que discuté dans GitMinutes l'épisode 17, par Nicolas Zakas, dans son article sur "GitHub flux de travail à l'intérieur d'une société":
Git-flow est un processus de gestion des changements dans Git qui a été créé par Vincent Driessen et accompagné de certaines extensions Git pour gérer ce flux.
L'idée générale derrière git-flow est d'avoir plusieurs branches distinctes qui existent toujours, chacun dans un but différent:master,develop,feature,release, ethotfix.
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é avecgit-flowet s'en sont éloignés.La principale raison de l'abandon est que le processus
git-flowest difficile à gérer dans un modèle de déploiement continu (ou quasi continu).
Le sentiment général est que legit-flowfonctionne bien pour les produits dans un modèle de version 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 publiez une fois par jour ou plus.
En bref:
Commencez par un modèle aussi simple que possible (comme le flux GitHub a tendance à l'être), et déplacez-vous vers un modèle plus complexe si vous en avez besoin.
Vous pouvez voir une illustration intéressante d'unsimple workflow, basé sur Github-Flow à:
"Un modèle de branchement simple git", avec les éléments principaux étant:
masterdoit toujours être déployable.- toutes les modifications apportées par les branches d'entités (pull-request + merge)
- rebase pour éviter/résoudre les conflits; fusionner à
master
Il n'y a pas de workflow silver bullet où tout le monde devrait suivre, puisque 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 - utilisation de Git-flow
Si votre code a plusieurs versions en production (c'est-à-dire typique produits logiciels comme les systèmes D'exploitation, les paquets de bureau, la coutume applications, etc), vous pouvez utiliser git-flow. La raison principale est que vous avez besoin pour soutenir en permanence les versions précédentes en production tout en le développement de la prochaine version.
Seule la version en production d'un logiciel facile à utiliser Github-flux
Si votre code n'a qu'une seule version en production à tout moment (c'est à dire des sites web, services web, etc), vous pouvez utiliser github-flux. Principal la raison est que vous n'avez pas besoin de choses complexes pour le développeur. Une fois que le développeur a terminé une fonctionnalité ou terminé un bugfix c'est immédiatement promu à la version de production.
Version unique en production mais logiciel très complexe-utilisation Gitlab-flow
Grand Logiciel comme Facebook et Gmail, vous devrez peut-être introduire branches de déploiement entre votre branche et la branche maître où CI / CD > tools pourrait s'exécuter, avant d'entrer en production. L'idée est de introduire plus de protection à la version de production depuis son utilisé 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 façon dont votre application sera développée et déployée.
Cela fonctionne bien lorsque vous avez une application qui a un flux de développement/déploiement 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 je utilisez le flux GitHub.
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 de chance de gâcher les choses. Aussi 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, cela vous aidera avec les commandes, mais se souvenir du flux réel est votre travail, je suis venu à travers 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 ils ne peuvent pas se souvenir du flux et bourrer les choses.
Il existe au moins une interface graphique qui prend en charge git-flow Pour Mac et Windows SourceTree.
Ces jours-ci, je penche plus vers GitHub flow, en raison de sa simplicité et de sa facilité de gestion. En outre, en raison de "déployer tôt déployer souvent"...
J'espère que cela aide