Pourquoi tout le monde utilise Git de manière centralisée?
J'ai utilisé Git dans mes deux dernières sociétés pour le contrôle de version. D'après ce que j'ai entendu, environ 90% des entreprises utilisent Git par rapport à d'autres systèmes de contrôle de version.
L'un des principaux arguments de vente de Git est qu'il est décentralisé, c'est-à-dire que tous les référentiels sont égaux; il n'y a pas de dépôt central/source de vérité. C'était une fonctionnalité Linus Torvalds défendue.
Mais il semble que chaque entreprise a utilisé Git de manière centralisée, tout comme on utiliserait SVN ou CVS. Il y a toujours un référentiel central sur un serveur (généralement sur GitHub) à partir duquel les gens tirent et poussent. Je n'ai jamais vu ou entendu parler (dans mon expérience certes limitée) de personnes utilisant Git de la manière vraiment décentralisée dont il était destiné, c'est-à-dire poussant et tirant vers d'autres référentiels de collègues comme bon leur semblait.
Mes questions sont:
- Pourquoi les gens n'utilisent-ils pas un workflow distribué pour Git dans la pratique?
- La capacité de travailler de manière distribuée est-elle même importante pour le contrôle de version moderne, ou cela semble-t-il juste agréable?
Éditer
J'ai réalisé que je n'avais pas trouvé le ton correct dans ma question d'origine. Il me semblait que je demandais pourquoi quelqu'un travaillerait de manière centralisée alors qu'un système de contrôle de version distribué (DVCS) était si évidemment supérieur. En réalité, ce que je voulais dire était, Je ne vois aucun avantage pour DVCS . Pourtant, j'entends souvent des gens prêcher sa supériorité, tandis que le monde réel semble d'accord avec mon point de vue.
Ahh, mais en fait vous êtes en utilisant git de manière décentralisée!
Comparons le prédécesseur de git dans mindshare, svn. Subversion n'avait qu'un seul "repo", une seule source de vérité. Lorsque vous avez effectué une validation, c'était dans un seul référentiel central, auquel tous les autres développeurs s'engageaient également.
Ce genre de travail, mais il a conduit à de nombreux problèmes, le plus important étant le redouté conflit de fusion. Ceux-ci se sont avérés ennuyeux à cauchemardesques à résoudre. Et avec une seule source de vérité, ils avaient la mauvaise habitude d'arrêter le travail de tout le monde jusqu'à ce qu'ils soient résolus. Les conflits de fusion existent certainement avec git, mais ce ne sont pas des événements qui arrêtent le travail et sont beaucoup plus faciles et rapides à résoudre; ils n'affectent généralement que les développeurs impliqués dans les changements conflictuels, plutôt que tout le monde.
Ensuite, il y a tout le point de défaillance unique et les problèmes qui en découlent. Si votre dépôt svn central meurt d'une manière ou d'une autre, vous êtes tous vissés jusqu'à ce qu'il puisse être restauré à partir de la sauvegarde, et s'il n'y a pas eu de sauvegardes, vous êtes tous doublement vissés. Mais si le référentiel git "central" meurt, vous pouvez restaurer à partir de la sauvegarde, ou même à partir de l'une des autres copies du référentiel qui se trouvent sur le serveur CI, les postes de travail des développeurs, etc. Vous pouvez le faire précisément parce qu'ils sont distribués, et chaque développeur a une copie de première classe du dépôt.
D'un autre côté, puisque votre git repo is un repo de première classe à part entière, lorsque vous vous engagez, vos commits vont à votre repo local. Si vous souhaitez les partager avec d'autres, ou à la source centrale de vérité, vous devez explicitement le faire avec un Push vers une télécommande. D'autres développeurs peuvent ensuite supprimer ces modifications quand cela leur convient, plutôt que d'avoir à vérifier svn en permanence pour voir si quelqu'un a fait quelque chose qui va les gâcher.
Le fait que, au lieu de pousser directement vers d'autres développeurs, vous les indiquez indirectement via un autre référentiel distant, peu importe. La partie importante de notre point de vue est que votre copie locale du repo est un repo à part entière. Dans svn, la source centrale de vérité est renforcée par la conception du système. En git, le système n'a même pas ce concept; s'il existe une source de vérité, elle est décidée de l'extérieur.
Lorsque votre serveur de build (vous êtes en utilisant CI, n'est-ce pas?) Crée un build, d'où tire-t-il? Bien sûr, un build d'intégration dont vous pourriez discuter n'a pas besoin de "un vrai repo" mais sûrement un build de distribution (c'est-à-dire ce que vous donnez au client).
En d'autres termes: la fragmentation. Si vous désignez un dépôt comme "le" dépôt et nommez des tuteurs qui examinent les demandes de tirage, vous avez un moyen facile de satisfaire la demande de "donnez-moi une version logicielle" ou "je suis nouveau dans l'équipe, où est le code?"
La force du DVCS n'est pas tant l'aspect peer-to-peer, mais le fait qu'il soit hiérarchique. Je modifie mon espace de travail, puis je m'engage en local. Une fois que j'ai une fonctionnalité terminée, je fusionne mes validations et les pousse sur ma télécommande. Ensuite, n'importe qui peut voir mon code provisoire, fournir des commentaires, etc. avant de créer une demande d'extraction et un administrateur de projet la fusionne dans le référentiel One True.
Avec CVCS traditionnel, vous vous engagez ou non. C'est bien pour certains workflows (j'utilise les deux types de VCS pour différents projets), mais tombe à plat pour un projet public ou OSS. La clé est que DVCS comporte plusieurs étapes, ce qui représente plus de travail, mais offre un meilleur moyen d'intégrer du code provenant d'étrangers grâce à un processus intégré qui permet une meilleure visibilité sur ce qui est archivé. En l'utilisant de manière centralisée, vous pouvez toujours avoir cet étalon-or de l'état actuel du projet tout en offrant un meilleur mécanisme de partage de code.
Je ne sais pas comment vous définissez "tout le monde", mais mon équipe a "un référentiel central sur un serveur" et aussi de temps en temps, nous tirons des dépôts d'autres collègues sans passer par ce référentiel central . Lorsque nous faisons cela, nous allons toujours via un serveur, car nous choisissons de ne pas envoyer de correctifs par e-mail sur le lieu, mais pas via le référentiel central. Cela se produit généralement lorsqu'un groupe collabore sur une fonctionnalité particulière et souhaite se tenir au courant les uns des autres, mais n'a pas encore intérêt à publier la fonctionnalité pour tout le monde. Naturellement, puisque nous ne sommes pas des travailleurs clandestins, ces situations ne durent pas longtemps, mais DVCS offre la flexibilité de faire ce qui est le plus pratique. Nous pouvons publier une branche de fonctionnalité ou non selon les goûts.
Mais 90% + du temps, bien sûr, nous passons par le repo central. Lorsque je ne me soucie pas d'un changement particulier ou du travail d'un collègue en particulier, il est plus pratique, et il évolue mieux, de tirer "tous les changements de mes collègues qui ont été vérifiés dans le référentiel central", plutôt que de tirer séparément les changements de chacun des N collègues. DVCS n'essaye pas d'empêcher le "pull from main repo" comme étant le workflow le plus courant, il essaie de l'empêcher d'être le seul workflow disponible.
"Distribué" signifie que tous les référentiels sont techniquement équivalents en ce qui concerne le logiciel git, mais il ne s'ensuit pas qu'ils ont tous une signification égale en ce qui concerne les développeurs et nos flux de travail. Lorsque nous publions sur des clients ou sur des serveurs de production, le référentiel que nous utilisons pour ce faire a une signification différente d'un référentiel utilisé uniquement par un développeur sur son ordinateur portable.
Si "vraiment décentralisé" signifie "il n'y a pas de repos spéciaux", alors je ne pense pas que c'est ce que Linus veut défendre, étant donné qu'en fait il fait maintient des repos spéciaux qui sont plus important dans le grand schéma des choses, que ne l'est un clone aléatoire de Linux que j'ai fait hier et que je prévois d'utiliser uniquement pour développer un petit correctif, puis le supprimer une fois qu'il aura accepté le correctif. git ne privilégie pas son dépôt sur le mien, mais Linus le fait le privilégie. Son "est l'état actuel de Linux", pas le mien. Alors change naturellement tendance pour passer par Linus. La force du DVCS sur le VCS centralisé n'est pas qu'il ne doit pas y avoir de centre de facto, c'est que les changements ne doivent passer par aucun centre parce que (si les conflits le permettent), n'importe qui peut fusionner n'importe quoi.
Les systèmes DVCS sont également forcés, car ils sont décentralisés, pour fournir certaines fonctionnalités pratiques basées sur le fait que vous devez nécessairement avoir un historique complet (c'est-à-dire un dépôt) localement pour faire quoi que ce soit. Mais si vous y réfléchissez, il n'y a aucune raison fondamentale pour laquelle vous ne pouvez pas configurer un VCS centralisé avec un cache local qui conserve l'historique complet des opérations en lecture seule autorisées à être obsolètes (je pense que Perforce a une option pour ce mode, mais je n'ai jamais utilisé Perforce). Ou en principe, vous pouvez configurer git avec votre .git/ répertoire sur un système de fichiers monté à distance afin d'émuler la "fonctionnalité" de SVN qui ne fonctionne pas lorsque vous n'avez pas de connexion réseau. En effet, DVCS oblige la plomberie à être plus robuste que vous ne pouvez vous en sortir dans un VCS centralisé. Ceci est un effet secondaire (très bienvenu) et a contribué à motiver la conception du DVCS, mais cette répartition des responsabilités au niveau technique n'est pas la même que la décentralisation complète de toutes les responsabilités humaines.
La chose intéressante à propos de la nature du DVCS, c'est que si d'autres personnes l'utilisent de manière distribuée, vous ne le sauriez probablement pas à moins qu'elles n'interagissent directement avec vous. La seule chose que vous pouvez dire définitivement est que vous et vos coéquipiers directs n'utilisent pas git de cette façon. Cela ne nécessite pas de politique à l'échelle de l'entreprise. Je vais donc vous demander pourquoi ne pas vous utiliser git de manière décentralisée?
Pour traiter votre modification, vous avez peut-être besoin d'une certaine expérience de travail avec un contrôle de version centralisé réel pour apprécier les différences, car bien qu'elles puissent sembler subtiles, elles sont omniprésentes. Ce sont toutes les choses que mon équipe fait réellement au travail que nous ne pouvions pas faire lorsque nous avions centralisé VCS:
- Avoir une très petite liste de développeurs principaux avec un accès de validation au référentiel "central" pour chaque microservice. Tout le monde peut travailler sur des fourches et soumettre via des demandes de tirage.
- Peut s'engager beaucoup plus fréquemment, généralement plusieurs fois par heure contre une ou deux fois par jour.
- Peut créer des branches pour n'importe quelle raison pour se coordonner temporairement avec des collègues, et appuyez dessus et tirez-en plusieurs fois par jour, puis écrasez-le lorsque vous êtes prêt à partager avec un groupe plus important. Avez-vous une idée de la difficulté d'obtenir la permission de créer une branche temporaire pour quelque chose comme ça dans un CVCS traditionnel?
Au risque de paraître vieux pour le dire, vous ne savez vraiment pas à quel point vous l'avez facile.
Je pense que votre question vient d'un état d'esprit (compréhensible) toujours connecté . c'est-à-dire. Le serveur central ci-dessous 'vérité' est toujours (ou presque toujours) disponible. Bien que cela soit vrai dans la plupart des environnements, j'ai travaillé dans au moins un qui était loin de cela.
Un projet de simulation militaire sur lequel mon équipe a travaillé il y a plusieurs années. Tous le code (Nous parlons d'une base de code> 1 $ US) devait (par la loi/accord international, les hommes dans des costumes sombres viennent si vous ne l'êtes pas) sur des machines physiquement isolé de toute connexion Internet . Cela signifiait la situation habituelle où nous avions chacun 2 PC, l'un pour écrire/exécuter/tester le code, l'autre pour Google, vérifier les e-mails et autres. Et il y avait un réseau local au sein de l'équipe de ces machines, évidemment pas du tout connecté à Internet.
La "source centrale de vérité" était une machine sur une base militaire, dans une pièce souterraine sans fenêtre entièrement en parpaings (bâtiment renforcé, yada-yada). Cette machine aussi n'avait pas de connexion Internet.
Périodiquement, ce serait le travail de quelqu'un de transporter (physiquement) un lecteur avec le git repo (contenant tous nos changements de code) à la base militaire - qui était à plusieurs centaines de kilomètres, alors, vous pouvez imaginer.
De plus, dans de très grands systèmes où vous avez lots d'équipes. Ils auront généralement chacun leur propre référentiel "central", qui revient ensuite au référentiel central "central" réel (niveau divin). Je connais au moins un autre entrepreneur qui a fait le même tableau de bord git repo avec leur code.
De plus, si vous considérez quelque chose à l'échelle du noyau Linux ... Les développeurs n'envoient pas simplement une requête pull à Linus lui-même. C'est essentiellement une hiérarchie de repo - dont chacun était/est "central" pour quelqu'un/une équipe.
La nature déconnectée de git signifie qu'il peut être utilisé dans des environnements où connecté modélise les outils de contrôle de source ( ie SVN, pour un) ne pouvait pas être utilisé - ou ne pouvait pas être utilisé aussi facilement.
En fin de compte, vous construisez un produit. Ce produit représente votre code à un moment donné. Étant donné que, votre code doit fusionner quelque part. Le point naturel est un serveur ci ou un serveur central à partir duquel le produit est construit, et il est logique que ce point central soit un référentiel git.
L'aspect distribué d'un DVCS apparaît tout le temps dans le développement open source, sous forme de forking. Par exemple, certains des projets auxquels je contribue ont été abandonnés par l'auteur original et ont maintenant un tas de fourchettes où les mainteneurs tirent parfois des fonctionnalités spécifiques les uns des autres. Même en général, les projets OSS prennent des contributions externes via une demande de tirage, plutôt qu'en accordant à des personnes aléatoires un accès Push au référentiel de vérité.
Ce n'est pas un cas d'utilisation très courant lors de la construction d'un produit en béton avec une version officielle spécifique, mais dans le monde F/OSS, c'est la norme, pas l'exception.
Pourquoi tout le monde utilise-t-il git de manière centralisée?
Nous ne nous sommes jamais rencontrés, comment se fait-il que vous disiez tout le monde? ;)
Deuxièmement, il existe d'autres fonctionnalités que vous trouvez dans Git mais pas dans CVS ou SVN. Peut-être que c'est juste vous en supposant que cela doit être la seule fonctionnalité pour tout le monde .
Bien sûr, beaucoup de gens peuvent l'utiliser de manière centralisée comme CVS ou SVN. Mais n'oubliez pas l'autre fonctionnalité qui est intrinsèquement fournie avec un VCS distribué: toutes les copies sont plus ou moins "complètes" (toutes les branches et l'historique complet sont disponibles) et toutes les branches peuvent être extraites sans se connecter à un serveur.
Je pense que c'est une autre caractéristique à ne pas oublier.
Bien que vous ne puissiez pas le faire avec CVS et SVN prêts à l'emploi, Git peut être utilisé de manière centralisée comme les anciens sans aucun problème.
Je peux donc valider mes modifications, peut-être écraser les validations de travaux en cours ensemble, puis récupérer et rebaser mon travail dans la branche principale de développement.
Autres fonctionnalités qui sortent de la boîte avec Git:
- signer cryptographiquement les commits
- rebasage (réorganiser et valider les validations; modifier les validations, pas seulement le message)
- cueillette de cerises
- bissectrice de l'histoire
- les succursales locales et les changements de dissimulation (appelés "étagères" dans Wikipedia)
Voir également ces trois tableaux dans Wikipedia - Comparaison des logiciels de contrôle de version :
Encore une fois, la manière décentralisée n'est peut-être pas la seule caractéristique qui incite les gens à l'utiliser.
- Pourquoi les gens n'utilisent-ils pas un workflow distribué pour Git dans la pratique?
Quiconque contribue ou héberge un projet plus important sur Bitbucked, GitHub, etc. le fera exactement. Les mainteneurs conservent le référentiel "principal", un contributeur clone, valide puis envoie une pull request.
Dans les entreprises, même avec de petits projets ou équipes, un flux de travail distribué est une option lorsqu'ils externalisent des modules et ne veulent pas que les externes modifient la ou les branches de développement sacrées sans que leurs modifications soient examinées auparavant.
- La capacité de travailler de manière distribuée est-elle encore importante pour le contrôle de version moderne, ...
Comme toujours: cela dépend des exigences.
Utilisez un VCS décentralisé si un point s'applique:
- souhaitez engager ou parcourir l'historique hors ligne (c'est-à-dire terminer le sous-module dans la cabane de montagne pendant les vacances)
- fournir un référentiel central mais vouloir garder le "vrai" référentiel à part pour examiner les changements (c'est-à-dire pour les grands projets ou les équipes réparties)
- vouloir fournir (une copie de) l'historique complet et les branches de temps en temps tout en empêchant l'accès direct au référentiel central (similaire au second)
- voulez versionner quelque chose sans avoir à le stocker à distance ou à configurer un référentiel dédié (en particulier avec Git un simple
git init .ce serait suffisant pour être prêt à versionner quelque chose)
Il y en a d'autres mais quatre devraient suffire.
... ou ça sonne juste bien?
Bien sûr, cela semble agréable - pour les débutants.
La flexibilité est à la fois une malédiction et une bénédiction. Et comme Git est extrêmement flexible, il est presque toujours loin trop flexible pour la situation typique. Plus précisément, la plupart des projets Git ne sont pas Linux.
En conséquence, le choix intelligent est de supprimer une partie de cette flexibilité théorique lors de la mise en œuvre de Git. En théorie, les référentiels peuvent former n'importe quel graphique, en pratique le choix habituel est un arbre. Nous pouvons voir les avantages évidents en utilisant la théorie des graphes: dans une arborescence de référentiels, deux référentiels quelconques partagent exactement un ancêtre. Dans un graphe aléatoire, l'idée d'un ancêtre n'existe même pas!
Cependant, votre client git utilise presque certainement le modèle "ancêtre unique". Et les graphiques dans lesquels les nœuds ont un seul ancêtre (à l'exception d'un nœud racine) sont exactement des arbres. Par conséquent, votre client git lui-même utilise par défaut le modèle d'arbre, et donc les référentiels centralisés.
La logique métier récompense un serveur centralisé. Pour presque tous les scénarios d'entreprise réalistes, un serveur centralisé est une caractéristique fondamentale du flux de travail.
Ce n'est pas parce que vous avez la capacité de faire du DVCS que votre flux de travail principal doit être le DVCS. Lorsque j'utilise git au travail, nous l'utilisons de manière centralisée, à l'exception de ces étranges cas étranges où le bit distribué était essentiel pour faire avancer les choses.
Le côté distribué des choses est compliqué. En règle générale, vous voulez que les choses restent fluides et faciles. Cependant, en utilisant git, vous vous assurez d'avoir accès au côté distribué pour faire face aux situations noueuses qui peuvent survenir en cours de route.
Pour qu'un collègue tire d'un git repo sur ma machine, je dois avoir un démon git en cours d'exécution au niveau racine comme tâche d'arrière-plan. Je suis très méfiant des démons fonctionnant sur mon propre ordinateur ou sur mon ordinateur portable fourni par l'entreprise. La solution la plus simple est "NON"! Pour qu'un collègue tire d'un git repo sur ma machine, cela signifie également que mon adresse Internet doit être corrigée. Je voyage, je travaille à domicile et je travaille parfois à mon bureau.
D'un autre côté, VPNing sur le site de l'entreprise et pousser une succursale vers le référentiel central prend moins d'une minute. Je n'ai même pas besoin de VPN si je suis au bureau. Mes collègues peuvent facilement se retirer de cette branche.
D'un autre côté, mon dépôt git local est un référentiel complet. Je peux engager de nouveaux travaux, créer une nouvelle branche pour des travaux expérimentaux et revenir au travail lorsque je fais des dégâts, même lorsque je travaille dans un avion volant à 30 000 pieds au milieu de nulle part. Essayez de le faire avec un système de contrôle de version centralisé.
Complexité:
Avec un référentiel central, un flux de travail typique peut être
branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and Push
La complexité par rapport au nombre de développeurs dans O (1).
Si, à la place, chaque développeur a sa propre branche principale, cela devient, pour le développeur 0:
branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0
L'approche poste à poste est O (N).
Cohérence:
Considérez maintenant s'il y a un conflit de fusion entre la branche principale d'Alice et la branche principale de Bob. Chacun des N développeurs pourrait résoudre le conflit différemment. Résultat: le chaos. Il existe des moyens de parvenir à une cohérence éventuelle, mais jusqu'à ce que cela se produise, toutes sortes de temps de développement peuvent être perdus.
Facile:
Les entreprises sont des organisations centralisées, avec un flux de travail centralisé.
Chaque programmeur a un patron et il a son patron, etc. jusqu'au CTO. Le CTO est la source ultime de vérité technique. Quel que soit l'outil utilisé par l'entreprise, il doit refléter cette chaîne de commandement. Une entreprise est comme une armée - vous ne pouvez pas laisser des soldats l'emporter sur un général.
GIT offre des fonctionnalités qui sont utiles aux entreprises (par exemple, tirer des demandes de révision de code) et qui seules les font passer à GIT. La partie décentralisée est simplement une fonctionnalité dont ils n'ont pas besoin - ils l'ignorent donc.
Pour répondre à votre question: La partie distribuée est en effet supérieure en environnement distribué, par exemple open-source. Les résultats varient selon qui parle. Linus Torvalds n'est pas exactement votre rat de cabine, c'est pourquoi différentes fonctionnalités de GIT sont importantes pour lui que pour votre entreprise centrée sur le github.