Pourquoi tout le monde utilise-t-il Git de manière centralisée?

J'ai utilisé Git dans mes deux sociétés précédentes 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 référentiel central / source de vérité. C’est une caractéristique que Linus Torvalds a défendue .

Mais il semble que chaque entreprise utilise Git de manière centralisée, comme on utiliserait SVN ou CVS. Il existe toujours un référentiel central sur un serveur (généralement sur GitHub) depuis lequel les utilisateurs puisent et poussent. Je n'ai jamais vu ni entendu parler (selon mon expérience, certes limitée) de personnes utilisant Git de la manière réellement décentralisée dont il avait été conçu, c'est-à-dire de pousser et de tirer les dépôts d'autres collègues à sa guise.

Mes questions sont:

1. Pourquoi les gens n'utilisent-ils pas un workflow distribué pour Git?
2. Est-ce que la capacité à travailler de manière distribuée est même importante pour le contrôle de version moderne, ou est-ce que ça sonne bien?

Modifier

J'ai réalisé que je n'avais pas compris le ton juste dans ma question initiale. On aurait dit que je demandais pourquoi quelqu'un travaillerait de manière centralisée alors qu'un système de contrôle de version distribuée (DVCS) était si nettement supérieur. En réalité, ce que je voulais dire, c’est que je ne vois aucun avantage pour DVCS . Pourtant, j'entends souvent des gens prêcher sa supériorité, alors que le monde réel semble être d'accord avec moi.

Ahh, mais en fait , vous êtes utilisez git de manière décentralisée!

Comparons le prédécesseur de git dans le partage des idées, svn. Subversion n'avait qu'un "repo", une source de vérité. Lorsque vous avez fait un engagement, il s’agissait d’un seul dépôt central auquel tous les autres développeurs s’engageaient également.

Cela a fonctionné, mais cela a engendré de nombreux problèmes, le plus important étant le redoutable conflit de fusion . Celles-ci se sont avérées être ennuyeuses ou cauchemardesques à résoudre. Et avec une 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 bien avec git, mais ce ne sont pas des événements bloquants et sont beaucoup plus faciles et rapides à résoudre; ils n'affectent généralement que les développeurs impliqués dans les modifications conflictuelles, plutôt que tout le monde.

Il y a ensuite tout le point de défaillance unique et les problèmes qui en découlent. Si votre svn repo central meurt d'une manière ou d'une autre, vous êtes tous vissés jusqu'à ce qu'il puisse être restauré à partir d'une sauvegarde. S'il n'y avait pas de sauvegardes, vous êtes tous doublement foutus. Mais si le repo git "central" meurt, vous pouvez restaurer à partir d'une sauvegarde, ou même à partir de l'une des autres copies du repo qui se trouvent sur le serveur CI, sur les stations de travail des développeurs, etc. Vous pouvez le faire précisément parce qu'elles sont distribuées, et chaque développeur dispose d'une copie de première classe du rapport.

D'autre part, comme votre dépôt git est un dépôt de première classe à part entière, lorsque vous vous engagez, vos commits sont envoyés à votre dépôt local. Si vous souhaitez les partager avec d'autres personnes ou avec la source centrale de la vérité, vous devez le faire explicitement en poussant une télécommande. Les autres développeurs peuvent alors effectuer ces modifications à leur convenance, sans avoir à vérifier constamment svn pour voir si quelqu'un a fait quelque chose qui les ferait foirer.

Le fait que, au lieu de pousser directement les autres développeurs, vous leur appliquez des modifications indirectement via un autre référentiel à distance, importe peu. La partie importante de notre point de vue est que votre copie locale de la pension est une pension à part entière. Dans svn, la source centrale de la vérité est renforcée par la conception du système. Dans git, le système n'a même pas ce concept; s'il y a une source de vérité, c'est décidé de l'extérieur.

Lorsque votre serveur de build (vous êtes utilisez CI, à droite?) Crée une construction, où est - il tirer de? Bien sûr, une construction d'intégration que vous pourriez argumenter n'a pas besoin de "un véritable référentiel", mais bien d'une compilation de distribution (c'est-à-dire de ce que vous donnez au client).

En d'autres termes: fragmentation. Si vous désignez un référentiel comme "le" référent et nomme les gardiens qui vérifient les demandes de tirage, vous avez un moyen facile de satisfaire la demande de "donnez-moi une version logicielle" ou de "je suis nouveau dans l'équipe, où est le code?"

La force de DVCS n’est pas tant l’aspect peer-to-peer, mais le fait qu’elle soit hiérarchique . Je modifie mon espace de travail, puis je m'engage à local. Une fois la fonction terminée, je fusionne mes commits et les pousse sur ma télécommande. Ensuite, tout le monde peut voir mon code de tentative, fournir des commentaires, etc. avant de créer une demande d'extraction et qu'un administrateur de projet le fusionne dans le référentiel One True.

Avec le CVCS traditionnel, vous vous engagez ou vous ne le faites pas. Cela convient pour certains flux de travail (j'utilise les deux types de VCS pour différents projets), mais ne convient pas pour un projet public ou OSS. L’essentiel est que DVCS comporte plusieurs étapes, qui demandent plus de travail, mais qui offrent un meilleur moyen d’intégrer le code d’étrangers via un processus intégré qui permet une meilleure visibilité de ce qui est archivé. Son utilisation de manière centralisée vous permet de avoir cet étalon-or de l'état actuel du projet tout en fournissant un meilleur mécanisme de partage de code.

Je ne sais pas comment vous définissez « tout le monde », mais mon équipe a « un repo central sur un serveur » et aussi de temps en temps nous tirer à partir des prises en pension d'autres collègues sans passer par cette prise en pension centrale. Lorsque nous faisons cela, nous passons toujours via un serveur, car nous avons choisi de ne pas envoyer de correctifs par e-mail sur l’endroit, mais pas via le référentiel central. Cela se produit généralement lorsqu'un groupe collabore sur une fonctionnalité particulière et veut se tenir au courant les uns des autres, sans pour autant avoir intérêt à la publier à tout le monde. Naturellement, comme nous ne sommes pas des silos-ouvriers secrets, ces situations ne durent pas longtemps, mais DVCS offre la flexibilité nécessaire pour faire ce qui est le plus pratique. Nous pouvons publier une fonctionnalité ou non selon les goûts.

Mais plus de 90% du temps, bien sûr, nous passons par le dépôt 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 plus facile de retirer "tous les changements de mes collègues qui ont été approuvé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'essaie pas d'empêcher que "l'extraction du référentiel principal" soit le flux de travail le plus courant, il tente d'empêcher que ce soit le seul flux de travail disponible.

"Distribué" signifie que toutes les mises en pension sont techniquement équivalentes en ce qui concerne le gitlogiciel, mais cela ne signifie pas qu'elles ont toutes la même importance en ce qui concerne les développeurs et nos flux de travail. Lorsque nous livrons aux clients ou aux serveurs de production, le référentiel utilisé a une signification différente de celui utilisé par un seul développeur sur leur ordinateur portable.

Si « vraiment décentralisé » signifie « il n'y a pas de prises en pension spéciales » je ne pense pas que ce soit ce que Linus signifie champion, étant donné que en fait il ne maintenir repos spéciaux qui sont plus importantes dans le grand schéma des choses, que ce qui est Un clone aléatoire de Linux que j'ai créé hier et que je prévois d'utiliser uniquement pour développer un petit correctif, puis le supprimer une fois qu'il l'a accepté. gitne privilégie pas son repo sur la mienne, mais Linus ne privilège. Son "est l'état actuel de Linux", le mien ne l'est pas. Donc, naturellement, les changements ont tendancepasser par Linus. La force du DVCS par rapport au VCS centralisé ne réside pas dans le fait qu’il ne doit pas y avoir de centre de facto, mais que les changements ne doivent pas nécessairement passer par un centre, car (les conflits le permettent), tout le monde peut tout fusionner.

Les systèmes DVCS sont également obligés , du fait qu’ils sont décentralisés, de fournir certaines fonctionnalités pratiques basées sur le fait que vous devez nécessairement disposer d’un historique complet (c’est-à-dire d’un repo) localement pour pouvoir faire quoi que ce soit. Mais si vous y réfléchissez, il n’ya aucune raison fondamentale pour laquelle vous ne pourriez pas configurer un VCS centralisé avec un cache local qui conserve l’historique complet des opérations en lecture seule autorisé à être obsolète (je pense que Perforce a une option pour ce mode, mais je n'ai jamais utilisé Perforce). Ou en principe, vous pouvez configurer gitavec votre.git/répertoire sur un système de fichiers monté à distance afin d’émuler la "fonctionnalité" de SVN selon laquelle il ne fonctionne pas si vous n’avez pas de connexion réseau. En effet, DVCS oblige la plomberie à être plus robuste que ce que vous pouvez obtenir avec un VCS centralisé. Ceci est un effet secondaire (très bienvenu) et a contribué à motiver la conception de DVCS, mais cette répartition des responsabilités au niveau technique n’est pas la même chose que la décentralisation totale de toute responsabilité humaine .

La chose intéressante à propos de la nature de DVCS est que si d’autres personnes l’utilisent de manière distribuée, vous ne le saurez probablement pas à moins d’interagir directement avec vous. La seule chose que vous puissiez dire définitivement est que vous et vos coéquipiers directs n'utilisez pas git de cette façon. Cela ne nécessite pas de politique d'entreprise. Je vais donc vous demander, pourquoi n'utilisez- vous pas 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 quand nous avions centralisé VCS:

• Ayez une très petite liste de développeurs principaux disposant d'un accès de validation au dépôt "central" pour chaque microservice. Tout le monde peut travailler à partir de fourchettes et soumettre via des demandes d'extraction.
• Peut commettre beaucoup plus fréquemment, généralement plusieurs fois par heure, une ou deux fois par jour.
• Peut créer des branches pour quelque raison que ce soit, pour coordonner temporairement avec des collègues, et y pousser et en tirer plusieurs fois par jour, puis l'écraser lorsqu'il est prêt à être partagé avec un groupe plus important. Savez-vous combien il est difficile d’obtenir la permission de créer une branche temporaire pour quelque chose comme cela dans un système CVCS traditionnel?

Au risque de paraître vieux pour le dire, vous ne savez vraiment pas à quel point vous l'avez facilement.

Je pense que votre question vient d'un état d'esprit (compréhensible) toujours connecté . C'est-à-dire que le serveur central «vérité» ci est toujours (ou presque) disponible. Bien que cela soit vrai dans la plupart des environnements, j'ai travaillé dans au moins un pays qui était loin de cela.

Un projet de simulation militaire sur lequel mon équipe a travaillé il y a plusieurs années. Tout le code (nous parlons d'une base de code supérieure à 1 milliard de dollars) devait ( conformément à la loi / aux accords internationaux, des hommes en costume sombre viennent si vous ne le faites pas) être sur des machines physiquement isolées de toute connexion Internet . Cela signifiait que la situation habituelle était que nous avions chacun 2 ordinateurs, l’un pour écrire / exécuter / tester le code, l’autre pour Google, vérifier les courriels, etc. Et il y avait un réseau local au sein de l'équipe de ces machines, évidemment pas connecté à Internet.

La "source centrale de vérité" était une machine installée sur une base militaire, dans une salle souterraine sans fenêtres entièrement recouverte de parpaings (bâtiment renforcé, yada-yada). Cette machine a également eu aucune connexion Internet.

Périodiquement, ce serait le travail de quelqu'un de transporter (physiquement) un disque avec le dépôt git (contenant tous nos changements de code) vers la base militaire - qui se trouvait à plusieurs centaines de kilomètres, imaginez-vous.

De plus, dans les très grands systèmes où vous avez beaucoup d’équipes. Ils auront généralement chacun leur propre repo "central", qui retourne ensuite au repo central "central" actuel (niveau de dieu). Je connais au moins un autre entrepreneur qui a fait le même tirage dur avec son code.

En outre, si vous envisagez quelque chose à l'échelle du noyau Linux ... Les développeurs n'envoient pas simplement une demande d'extraction à Linus lui-même. Il s’agit essentiellement d’une hiérarchie de pensions - dont chacune était / est "centrale" pour une personne / une équipe.

La nature déconnecté des git signifie qu'il peut être utilisé dans des environnements où connectés outils source de contrôle modèle ( c. -à- SVN, pour un) ne pouvaient pas être utilisés - ou ne pouvait être utilisé aussi facilement.

En fin de compte, vous construisez un produit. Ce produit représente votre code à un moment donné. Compte tenu de cela, votre code doit fusionner quelque part . Le point naturel est un serveur ci ou un serveur central à partir duquel le produit est construit. Il est donc 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 la forme de forking. Par exemple, certains des projets auxquels j'ai contribué ont été abandonnés par l'auteur d'origine et comportent désormais un ensemble de fourchettes dans lesquelles les mainteneurs extraient parfois des fonctionnalités spécifiques les uns des autres. Même en général, les projets OSS acceptent des contributions extérieures via une demande d'extraction, plutôt que d'octroyer des accès aléatoires à des personnes qui poussent l'accès au référentiel.

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 des 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, vous trouverez d'autres fonctionnalités dans Git, mais pas dans CVS ou SVN. Peut-être que c'est juste 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é inhérente à 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 connexion à un serveur.

Je suis d’avis que c’est une autre caractéristique à ne pas oublier.

Bien que vous ne puissiez pas faire cela avec les systèmes CVS et SVN prêts à l'emploi, Git peut être utilisé de manière centralisée comme les anciens sans aucun problème.

Je suis donc en mesure de valider mes modifications. Peut-être que les travaux en cours de squash sont validés ensemble, puis de récupérer et de baser mon travail sur la branche de développement principale.

Autres fonctionnalités qui sortent de la boîte avec Git:

• signer de façon cryptographique
• rebasement (réordonne et squash les commits; édite les commits, pas seulement le message)
• la cueillette des cerises
• bissecter l'histoire
• branches locales et changements cachés (appelés "shelving" dans Wikipedia)

Voir également ces trois tableaux dans Wikipedia - Comparaison du logiciel de contrôle de version :

• Caractéristiques

• Commandes de base

• Commandes avancées

Encore une fois, peut-être que la manière décentralisée n'est pas la seule caractéristique qui incite les gens à l'utiliser.

1. Pourquoi les gens n'utilisent-ils pas un workflow distribué pour Git?

Quiconque contribue ou héberge un projet plus important sur Bitbucked, GitHub, etc. le fera de manière exacte. Les mainteneurs conservent le référentiel "principal", un clone contributeur, des validations, puis une requête d'extraction.

Dans les entreprises, même avec de petits projets ou équipes, un flux de travail distribué est une option lorsqu'elles externalisent des modules et ne veulent pas que les externes modifient la ou les branches de développement sacrées sans que leurs modifications aient été examinées auparavant.

2. La capacité fonctionne-t-elle de manière distribuée même importante pour le contrôle de version moderne, ...

Comme toujours: cela dépend des besoins.

Utilisez un VCS décentralisé si un point s'applique:

• vouloir s'engager ou naviguer dans l'historique hors ligne (c'est-à-dire terminer le sous-module dans la cabine de montagne pendant les vacances)
• fournir des repos centraux mais vouloir garder "le vrai" référentiel séparé pour examiner les modifications (par exemple pour les grands projets ou les équipes distribuées)
• vouloir fournir (une copie de) l'historique complet et les branches de temps en temps tout en empêchant un accès direct au référentiel central (similaire au second)
• Vouloir mettre à jour quelque chose sans avoir à le stocker à distance ou à mettre en place un référentiel dédié (surtout avec Git, git init .cela suffit pour être prêt à mettre quelque chose en version)

Il y en a d'autres mais quatre devraient suffire.

... ou est-ce que ça sonne bien?

Bien sûr, ça sonne bien - pour les débutants.

La flexibilité est une malédiction et une bénédiction. Et comme Git est extrêmement flexible, il est presque toujours beaucoup trop flexible pour une situation typique. Plus précisément, la plupart des projets Git ne sont pas Linux.

En conséquence, le choix judicieux consiste à 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 graphe. En pratique, le choix habituel est un arbre. Nous pouvons voir les avantages évidents de la théorie des graphes: dans un arbre de référentiels, deux référentiels 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. Ainsi, votre client git lui-même utilise par défaut le modèle d’arborescence, et donc les référentiels centralisés.

La logique métier récompense un serveur centralisé. Pour presque tous les scénarios de gestion 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 cas étranges et é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 se passent bien et facilement. Cependant, en utilisant git, vous vous assurez que vous avez accès au côté distribué pour faire face aux situations dangereuses qui peuvent survenir par la suite.

Pour qu'un collègue puisse extraire un dépôt Git sur ma machine, il faut qu'un démon git soit exécuté au niveau de la racine en tant que tâche en arrière-plan. Je suis très réticent à l'idée que des démons s'exécutent sur mon propre ordinateur ou sur l'ordinateur portable fourni par l'entreprise. La solution la plus simple est "NON"! Pour qu'un collègue tire d'un dépôt git sur ma machine, cela signifie également que mon adresse Internet doit être corrigée. Je voyage, je travaille à la maison et je travaille occasionnellement à partir de mon bureau.

En revanche, la connexion VPN vers le site de l'entreprise et le transfert d'une branche vers le référentiel central prennent moins d'une minute. Je n'ai même pas besoin de VPN si je suis au bureau. Mes collègues peuvent facilement tirer de cette branche.

Sur la troisième main, 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 en arrière lorsque je gâche un tas de choses, même lorsque je travaille dans un avion volant à 30 000 pieds au-dessus 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 au contraire, chaque développeur a sa propre branche principale, il 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 d'égal à égal est O (N).

Cohérence:

Examinons maintenant s’il existe 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. au CTO. CTO est la source ultime de la vérité technique. Quel que soit l'outil utilisé par l'entreprise, il doit refléter cette chaîne de commandement. Une compagnie est comme une armée - vous ne pouvez pas laisser des soldats déjouer un général.

GIT offre des fonctionnalités utiles aux entreprises (par exemple, des requêtes d'extraction pour la révision de code) et qui, à elles seules, les incitent à basculer vers 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 effectivement supérieure dans un environnement distribué, par exemple open-source. Les résultats varient selon qui parle. Linus Torvalds n’est pas exactement votre casier, c’est la raison pour laquelle les différentes fonctionnalités de GIT sont importantes pour lui plutôt que pour votre société centrée sur le github.

Peut-être est-ce dû au fait que le traitement de la paie est centralisé, nous devons donc garder une personne centrale heureuse si nous souhaitons être payés.

C’est peut-être parce que nous créons un seul produit. Nous avons donc besoin d’une copie originale du logiciel pour les clients.

Peut-être est-ce parce qu'il est beaucoup plus facile pour un programmeur de se rendre au même endroit pour obtenir les modifications de tout le monde, plutôt que de devoir se connecter à de nombreuses machines différentes.

Peut-être est-ce dû au fait que la base de données de bogues est centralisée et doit être synchronisée avec le code .

Être centralisé, c’est bien, jusqu’à ce qu’il y ait un problème… ..

Git étant un système distribué, un nouveau centre peut être créé à moindre coût à partir de tout référentiel mis à jour (il suffit d'exposer le référentiel au réseau). Git permet également de mettre à jour une sauvegarde obsolète à partir des référentiels des machines de développement, facilitant ainsi la restauration du centre.

Pouvoir fusionner, etc., sur une copie locale d'un référentiel lorsque le réseau est en panne est une excellente chose, mais ne nécessite pas de système distribué; il faut juste un système qui garde une copie locale de toutes les données. De même avec l'enregistrement du code avec voler, etc.

En fin de compte, la distribution et les avantages sont peu coûteux. La majeure partie du coût de la distribution se situe dans la zone requise si vous souhaitez un bon suivi des branches, etc. Si vous deviez concevoir un système utilisable dans la plupart des entreprises, vous ne le concevriez pas pour qu'il soit distribué, sous forme de contrôle centralisé du code source. est clairement le "cas d'utilisation" principal.