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


289

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.


31
Je ressens exactement la même chose et je ne comprends pas cela.
Snoop

57
Personnellement, je ne connais aucun cas d'utilisation de plusieurs télécommandes, autre que des fourches permettant de créer des relations publiques sur la télécommande principale. La solution distribuée est toujours utile car cela signifie que je reçois un historique complet sur ma machine sans avoir à parler au réseau, et que je peux travailler hors connexion si je le souhaite vraiment, et il est beaucoup plus facile de migrer d'un hôte de dépôt en ligne vers un autre. Qu'avez-vous à l'esprit lorsque vous vous référez à un "flux de travail distribué"?
Ixrec

43
Je suis à peu près certain que Torvalds avait l'intention dès le début de disposer d'un référentiel de noyau Linux "source de vérité".
Steven Burnap

67
En fin de compte, le logiciel lui - même est centralisé. Les clients n'achètent pas de branches ni de télécommandes, ils achètent un produit final, assemblé et construit. Il doit toujours y avoir une voie centrale à suivre.
Brandon

37
Pour moi, la "décentralisation" de Git est l'une des caractéristiques les moins importantes qui le recommandent. La capacité d'effectuer des commits et des retours en arrière fréquents localement, sans affecter qui que ce soit d'autre, ou des techniques puissantes telles que le rebasement sont les domaines où git brille vraiment dans mon flux de travail. Il est possible (voire probable) que tout cela soit rendu possible par la décentralisation, mais le "D" dans DVCS n'est pas si important en soi pour moi.
Jay

Réponses:


257

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.


15
Les fusions de SVN n'affectent également que les développeurs impliqués dans des modifications conflictuelles. Un commit est inclus dans le référentiel, aucune fusion en conflit ne peut y entrer tant que les conflits ne sont pas résolus (vous pouvez également commettre en parallèle dans une branche / un chemin séparé, mais cela ne crée pas de conflit, n'est-ce pas?)
Ben Voigt

30
Je trouve que la principale différence, lorsqu'un serveur central existe, est que GIT autorise le contrôle de version local en cours alors que le réseau est en panne, contrairement au SVN (certains autres systèmes de contrôle de version sont encore pires et arrêtent tout travail lorsque le réseau est inaccessible. , car ils ne vous permettent pas de modifier un fichier avant de l’avoir vérifié).
Ben Voigt

17
@ BenVoigt Oh, c'est un travail qui s'arrête bien. N'oubliez pas que vous devez svn upêtre à jour avec le référentiel avant de pouvoir vous enregistrer. Lorsque d'autres personnes continuent à s'enregistrer pendant que vous essayez de résoudre des conflits de fusion et vous attribuent un autre ensemble de conflits de fusion ... vous devez mettre un terme à cela. ou vous perdez ce qui reste de votre santé mentale.
Michael Hampton

21
Non, les personnes peuvent définitivement continuer à s’engager dans la branche à partir de laquelle vous fusionnez les modifications, sans interrompre votre flux de travail.
Ben Voigt

29
Ben a raison. Un référentiel SVN géré correctement et utilisé par une équipe correctement formée à la manière de développer des logiciels ne devrait en aucun cas avoir de conflit de fusion sur un tronc. Vous ne les obtiendrez que lorsque quelqu'un aura fait quelque chose de mal et doit être congédié (: P). Il est plus facile d'utiliser inb4 quand vous n'avez pas à apprendre aux gens comment utiliser leurs outils. Ouais, eh bien, il y a beaucoup plus à enseigner sur Git que sur SVN!
Courses de légèreté en orbite

118

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.


2
Dans l’ensemble, bonne réponse, mais je suis à peu près sûr que Git était largement utilisé avant l’intégration continue; Soit dit en passant, notre équipe utilise CI, merci d'avoir vérifié: D.
gardenhead

5
@gardenhead: vous avez manqué le point: le même argument est valable si on construit manuellement les intégrations. "CI" est juste une automatisation pour un processus beaucoup plus ancien que Git.
Doc Brown

25
"tout le monde peut voir mon code provisoire" et peut également extraire votre code provisoire, le fusionner avec son code provisoire et exécuter les tests. Cela pose un problème dans les VCS centralisés, car cela nécessite des branches et des modifications dans One True Copy. Distribué, vous configurez simplement des télécommandes supplémentaires, puis commencez à fusionner, à appliquer des correctifs et à sélectionner les données. Vous avez un suivi de ce que vous avez fait, mais personne d'autre n'a à voir les manigances que vous êtes en train de faire, sauf si vous choisissez de les publier. En général, je recommande que personne ne déclare le DVCS inutile tant qu'il n'a pas utilisé SVN pour un gros projet ...
Steve Jessop

9
Parce qu'il n'y a pas de "véritable construction" du noyau Linux. Puisque tout le monde le construit lui-même, le dépôt de Linus n’est pas plus canonique que celui de quiconque. Si vous vendez un produit qui ne fonctionne pas si bien.
Miles Budnek

2
@Superbest: une grande partie (sinon la totalité) du design de git était basée sur Bitkeeper. Git a été créé après l'implosion de la controverse linux-bitkeeper.
Whatsisname

40

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 .


7
Ils sont techniquement équivalents, pas socialement équivalents.
curieuxdannii

3
Envoyer des correctifs par courrier électronique est assez simple, juste au cas où quelqu'un le considérerait, utilisez simplement git format-patch , puis git send-email . C'est ce que j'ai fait lorsque je ne voulais pas manipuler les contrôles d'accès de Github et que c'était très simple, après tout, tout le monde avait un courrier électronique.
Rudolf Olah

1
"il faut nécessairement avoir une histoire complète [...] localement pour pouvoir faire quoi que ce soit" - ce n'est pas vrai; Les DSCM modernes supportent les prises en charge partielles ("checkouts superficiels" en termes réels, "clones superficiels" en termes génitaux).
Charles Duffy

27

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.


1
La question de savoir combien il est difficile de créer une branche dans un CVCS traditionnel est entièrement une question de politique: je travaille avec un référentiel SVN en amont (naturellement via un clone git-svn!), Et j'ai le droit de créer des branches I vouloir, même si c'est un assez grand projet. Je ne suis tout simplement pas autorisé à toucher un certain nombre de branches d'intégration désignées, sans parler du coffre, sans d'abord parler à mes supérieurs. D'autres entreprises peuvent avoir d'autres politiques qui peuvent être plus restrictives, mais ce n'est certainement pas nécessaire.
cmaster

7
Tu as raison, je ne sais pas à quel point c'est facile. J'aurais aimé être à l'époque de la domination du SVN pour apprécier le chemin parcouru. En tant que développeur de logiciel très jeune, je trouve ce même schéma qui se répète assez souvent: les développeurs plus expérimentés me disent que l'ancienne manière de faire quelque chose était mauvaise et que cette nouvelle méthode / technologie est beaucoup plus facile. Mais je dois juste prendre leur parole pour cela; Je ne pourrai jamais vraiment apprécier les avantages. J'ai toujours trouvé cette dissonance difficile à surmonter.
gardenhead

1
@gardenhead vous pouvez toujours créer votre propre dépôt SVN et essayer de le casser;) (et notez combien il est difficile de créer un dépôt git et de le cloner ...) - Une autre fonctionnalité majeure que j'ai remarquée (du moins dans En particulier dans les environnements d'entreprise), le partage de fichiers est soit un peu délicat, soit fait de telle sorte que les dépôts stockés (parce que l'analyseur de virus se verrouille sur un lecteur réseau, par exemple).
Wayne Werner

4
@gardenhead: eh bien, considérez que vous êtes chanceux de ne pas être bloqué dans un projet classique, avec d'anciens développeurs de logiciels qui vous disent que l'ancienne façon de faire les choses est très bien ... parfois vous ne pouvez pas vous empêcher de penser qu'ils ne sont que heureux qu'ils n'aient pas besoin d'apprendre de nouvelles technologies!
gauche du

1
@gardenhead apparemment, les projets sont publiés à un rythme assez insensé. La capacité de continuer à apprendre est nécessaire si vous voulez pouvoir trouver un emploi génial.
Wayne Werner

19

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.


3
Je suis membre du club Mile High (logiciel). J'ai commis un code à 35 000 pieds. Bien sûr, les avions ont maintenant le Wifi , mais ce n’a pas toujours été le cas. Et il est bon de savoir qu'au moins si nous tombons en panne, il est possible que mon équipe garde mon code intact.
Wayne Werner

@WayneWerner c'est vrai. J'avais pensé proposer des situations plus génériques où il n'était pas possible d'être (presque) toujours connecté. Par exemple, dans un avion, un bateau en mer, une station spatiale, des régions isolées d'Afrique, etc.
Tersosaure

18

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.


14

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.


4
C'est la bonne réponse, également d'un point de vue historique. Le noyau Linux dispose depuis longtemps de plusieurs référentiels sources (appelés "arbres" par les développeurs, tels que "arbre de Linus" ou "arbre d'Andrew"). Linux voulait quelque chose pour supporter ce type de développement distribué quand il développait git.
Sleske

@Luaan Après avoir réfléchi à cela pendant un moment, j'ai réalisé que tu avais raison. J'ai un peu changé le libellé - cela rend-il la distinction un peu mieux?
moelleux

@ Fluffy Cela me semble bien;)
Luaan

9

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 :

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.

  1. 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.


SVN n'a-t-il pas gagné svn inità un moment donné?
Immibis

5

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.


1
Je conviens que la flexibilité de Git doit être atténuée dans la plupart des cas d'utilisation. Lors de mon dernier emploi, nous n'avions pas de directives sur l'utilisation de git et il y avait des conflits et des ruptures constants à cause de cela. Dans ma nouvelle société, nous utilisons le modèle Git Flow, ce qui rend le développement beaucoup plus simple et sans stress.
Gardenhead

1
Ce n'est pas une "flexibilité théorique" d'autoriser les non-arbres. Limitez-vous aux "arbres uniquement" et vous ne pourrez jamais fusionner vos modifications, rendant ainsi votre VCS un peu inutile.
Wildcard

2
@Wildcard: La fusion ne pose aucun problème avec les arbres, pourquoi cela serait-il le cas? Vous ne pouvez pas fusionner entre des nœuds aléatoires, bien sûr, entre un parent / enfant.
MSalters

1
Je n'étais pas assez clair, évidemment. Je parlais d'un arbre de commits, pas d'un arbre de système de fichiers. Par définition, un commit de fusion a plus d'un parent et votre graphe d'historique n'est donc plus un arbre, mais un DAG.
Wildcard

2
@Wildcard: MSalters a déclaré que les référentiels sont généralement connectés en tant qu'arbres, mais que les commits ne le sont pas. Il dit que les pensions n'ont généralement qu'une seule télécommande "en amont" à laquelle elles poussent (ou émettent des demandes d'extraction). Je n'ai pas de statistiques sur le point de savoir si cela est vrai ou non, mais c'est une affirmation complètement distincte de tout ce qui a trait au nombre de parents d'un engagement de fusion.
Steve Jessop

4

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.


3

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é.


"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 de mon entreprise." - Parce qu'autre chose, exécuter un service sur mon ordinateur portable signifie que le service est indisponible lorsque je ferme le couvercle! DynDNS peut aider avec plusieurs emplacements (dans une certaine mesure, vous pouvez toujours être pris au piège derrière un NAT), mais cela n'aide pas à éteindre votre carte réseau ...
Steve Jessop

Il existe de nombreuses façons de rendre visible un dépôt git sans exécuter de démon spécial. il est accessible via pratiquement n'importe quel partage de fichiers (smb, sshfs, etc.), et peut même être rendu disponible en tant que simple magasin HTTP.
moelleux

2

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.


Si vous voulez voter par la baisse, pourriez-vous s'il vous plaît laisser un commentaire sur pourquoi?
Theodore Norvell

Pas que ça me dérange les votes négatifs. Je veux juste savoir si la réponse est fausse d'une certaine manière.
Theodore Norvell

1

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.


-2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.