Que puis-je faire pour les développeurs qui ne peuvent pas apprendre Git?

Question

Le contexte

Mon équipe de 8 ingénieurs est actuellement en transition vers Git (de Subversion) pour notre prochain gros truc. Nous avons une poignée d'ingénieurs "plus expérimentés" qui ont du mal à choisir Git. On me pose les mêmes questions triviales en dépit d'avoir fourni des manuels d'utilisation, des activités de formation et des séances de tableau blanc. Nous avions deux consultants juniors qui ont tout récupéré en quelques jours et cela a vraiment mis en lumière le problème. Ce n'est pas un modèle limité à Git mais il est devenu visible en conséquence.

Question

Je ne suis pas particulièrement favorable aux ingénieurs qui ne peuvent/ne veulent pas apprendre - en particulier le personnel avec les niveaux d'ancienneté que nous avons ici. Cependant, je veux que l'équipe réussisse et crée un excellent produit. Nous utilisons un modèle Git Flow centralisé et j'ai l'impression que toute la nouvelle terminologie les déroute.

Puis-je faire quelque chose pour aider ces employés à apprendre Git?

Sourcetree est le client utilisé par toute l'équipe.

Answer 1

Donnez-leur un jouet.

Git est dur. Surtout si vous avez fait du contrôle de code source dans un paradigme différent. J'ai cassé la version la première fois que j'ai essayé de travailler avec git. Cela m'a tellement paranoïaque que je n'ai pas voulu m'enregistrer avant que tout soit fait. Je cachais des versions dans des dossiers. Ensuite, j'ai enfin compris ce dont j'avais besoin pour le dépasser:

J'avais besoin d'un endroit sûr pour jouer.

Une fois que j'ai eu cela, je causais intentionnellement des problèmes afin que je puisse apprendre comment les résoudre - tous dans mon endroit sûr. J'ai développé un modèle que je pouvais utiliser même s'il était interrompu et je reviens toujours dans un bon état. Peu de temps après, des gens venaient me demander de l'aide avec Git. Tout ça parce que j'ai pris le temps de jouer avec un jouet.

Si vous les jetez dans le fond, vous aurez de la chance s'ils parviennent à flotter.

Answer 2

Le développeur moyen n'a pas besoin de beaucoup de goodies de git. C'est un système de contrôle de source distribué, mais la plupart des équipes l'utiliseront avec un référentiel canonique central pour pousser et tirer.

Les commandes de base dont votre équipe aura besoin sont:

• extraire et fusionner les modifications à distance et gérer les conflits résultants (éventuellement rebasage)
• commit et Push commits sur remote (ou Push sur staging repo/branch pour que les changements soient intégrés dans main après révision)
• Pour le support: corrigez les dégâts après avoir fait quelque chose de mal.

ceux dont les utilisateurs les plus avancés auront besoin sont

• gérer les validations locales
• gérer les succursales

Pour les personnes qui ne connaissent pas git et celles qui ne veulent pas l'apprendre, configurez quelques commandes alias rapides pour les faire et assurez-vous que tout est correct (ajoutez de nouveaux fichiers, supprimez les fichiers supprimés du référentiel, etc.)

Assurez-vous que ceux-ci sont bien documentés et décemment infaillibles.

C'est dans la veine de la bande dessinée xkcd , mémorisez simplement les commandes et espérez que les choses ne se gâchent pas trop, quand ils demandent à un professionnel.

Answer 3

Demandez-leur d'utiliser une interface utilisateur Git.

S'ils ont de l'expérience avec TortoiseSVN, TortoiseGit (Windows uniquement) fonctionne presque exactement de la même manière. Sinon, SourceTree (Windows + Mac) est merveilleux - nous avons plusieurs QA non-développeurs qui ont pu facilement maîtriser des tâches complexes dans Git grâce à SourceTree.

Answer 4

Cette réponse essaie de déterminer comment intéresser les programmeurs seniors à git, et non pas à apprendre git la manière la plus rapide - pour cela, l'excellent - git book est super, ou n'importe quelle quantité de tutoriels (=> Google). Les bons liens pour aller avec cette réponse sont Git est une structure de données purement fonctionnelle ou surtout le court Comment git stocke vos données .

J'ai bien peur d'avoir une vue assez sombre à ce sujet. J'ai été exactement à votre place - je suis un nerd git et je voulais transformer une équipe loin de svn avec, avouons-le, des résultats minuscules. Dans mon cas, cela m'a conduit à changer activement ma propre perception et à accepter que les gens ne peuvent tout simplement pas être "contraints au bonheur". Les gens ne sont pas des ordinateurs, c'est incroyablement difficile de les programmer. Je suis toujours content d'avoir essayé, cela m'a montré de manière assez douce ce que je fais et ce que je ne veux pas faire dans ma vie professionnelle.

Il y a des gens qui commencent à se motiver quand de nouvelles choses sont impliquées, et il y a ceux qui sont démotivés. Cela n'a rien à voir avec git, mais pour git en particulier, vous avez toujours pour effet "pourquoi devrions-nous l'utiliser du tout si svn est très bien?", Qui est une énorme barrière psychologique.

De plus, vraiment grokking git nécessite un intérêt intense pour les structures de données abstraites. Cela peut sembler incroyable, mais d'après mon expérience, il y a des programmeurs qui n'ont aucun intérêt du tout et qui s'ennuient et sont surchargés par des éléments plus complexes que les tableaux simples. Vous pouvez vous demander si ces personnes devraient faire le travail qu'elles font, mais c'est ce que c'est.

Si les gens ne s'y intéressent pas, ils ne le comprendront pas. Clair et simple. Je parierais que le désintérêt est la principale raison des mauvaises notes à l'école, ne manquant pas d'intelligence.

Cela dit, voici un programme tel que je l'appliquerais, basé sur une accumulation de connaissances de bas en haut. Cela n'a pas fonctionné pour moi, mais vous pouvez vous en inspirer pour lancer le vôtre.

GUI

Bien que l'approche suivante ne nécessite pas nécessairement la prise en charge de l'interface graphique pour les actions (git add dans un dépôt hello world ...), cela aide énormément d'avoir une interface graphique pour visualiser le référentiel, dès le début. Si vous ne pouvez pas décider lequel utiliser, prenez gitk en dernier recours. Si vos gars utilisent n'importe quel éditeur visuel, trouvez leur composant GUI git.

La structure de données (statique) est essentielle

Commencez par expliquer les types de données internes (il n'y en a que trois plus un: blobs, arbres, commits, balises annotées, dont le dernier ne présente aucun intérêt à ce stade) et leur structure. Vous pouvez facilement le faire sur un tableau blanc/avec un crayon; l'arbre est facile à dessiner car il ne peut jamais être changé, vous pouvez littéralement simplement ajouter des choses tout le temps. Vous pouvez effectuer une session de lecture dans un référentiel local fraîchement créé et utiliser git cat-file pour examiner les objets réels pour leur montrer qu'ils sont en fait aussi triviaux qu'annoncés.

Si vous pouvez les aider à comprendre que

• ... il n'y a littéralement que 3 types d'objets dans l'histoire, tous très simples, presque triviaux, et
• ... la plupart des sous-commandes git ne font que "masser" ces objets d'une manière ou d'une autre, avec des opérations quasi triviales (en gros, il n'y en a qu'une: ajouter un nouveau commit quelque part), et ...
• ... tout est facilement visible devant vous avec ls et git cat-file ...

alors ils auront la traduction mentale de ce qui est réellement dans le référentiel. À ce stade, les seniours peuvent se rappeler que les internes de svn sont de la magie arcanique (jamais eu des problèmes avec les verrous à l'intérieur du dépôt svn, ou avec des branches de "réintégration" et autres?), et cela peut simplement les motiver un peu.

Un problème, en particulier avec les gens habitués à svn, est de s'habituer à l'idée qu'un commit (l'objet, pas l'action) est toujours est l'ensemble de l'arborescence des répertoires. Dans svn, les gens sont utilisés pour valider des fichiers individuels. C'est une approche radicalement différente. Oh, et le fait que le même terme "commit" soit utilisé à la fois pour un objet statique et une action n'aide pas non plus.

L'autre problème pour les gars de svn est que svn utilise un historique linéaire, pas un arbre. C'est, encore une fois, très différent. C'est donc le temps de mettre en évidence ces différences beaucoup .

Actions expliquées en termes de structure

Quand ils ont compris de quelles parties est constitué un référentiel git, il est temps de leur montrer exactement ce que l'individu git les sous-commandes font en termes de ceux-ci.

Je parle de add, commit, en conjonction avec le répertoire de travail local et la scène (assurez-vous qu'ils comprennent que le répertoire de travail n'est pas le même que la zone de transfert qui n'est pas la même comme référentiel).

Quand ils ont compris que ces commandes font simplement grandir l'arbre (qui, encore une fois, à ce stade, se compose de 3 des types - blobs, arbres, commits , non seulement valide), vous pouvez faire un premier git Push et git pull (en mode d'avance rapide!) pour leur montrer que git ne fait littéralement que pousser ses objets, que les hachages sont vraiment seuls les hachages de contenu, que vous pouvez facilement copier autour avec une commande de copie du système de fichiers et ainsi de suite.

Évidemment, restez loin de toutes les options non essentielles de ces commandes, nous parlons git add hello.txt ici.

Branches

Notez que le branchement est particulièrement difficile pour les personnes svn, car il est totalement différent. Le modèle svn est beaucoup plus facile à visualiser, car il n'y a fondamentalement rien à visualiser - il est bien en vue. Le modèle git n'est pas tellement. Assurez-vous qu'ils sont conscients dès le départ que les branches et les balises ne sont que des "notes collantes" pointant quelque part et n'existent pas réellement en termes d'histoire statique et immuable.

Faites ensuite un exemple après un exemple simple pour montrer ce que vous pouvez réellement faire avec eux. Comme vous semblez être habitué à git, vous ne devriez avoir aucun mal à y trouver de la motivation. Assurez-vous qu'ils voient toujours cela en termes de croissance de l'arbre.

S'ils ont cela, vous pouvez expliquer comment git pull est vraiment git fetch && git merge; comment tous les référentiels contiennent exactement les mêmes objets (git fetch est presque la même chose que de copier des choses avec scp dans le répertoire de l'objet git) et ainsi de suite.

Probablement, si à ce moment-là vous n'avez pas atteint pour éveiller leur intérêt, alors vous pouvez tout aussi bien abandonner, mais s'ils parviennent à aller aussi loin, alors ils ont tous les outils mentaux à leur disposition, et il devrait y avoir peu la peur n'est plus en cause. Le reste (flux de travail git ...) devrait alors être en descente.

Derniers mots

Cela ressemble à beaucoup d'efforts, et c'est vraiment le cas. Ne vendez pas cela car "nous en avons besoin pour ce projet" mais "cela vous aide personnellement à vous développer et vous aidera dans toutes vos interactions futures". Vous avez besoin de beaucoup de temps pour cela, et le temps c'est de l'argent. Si vous n'êtes pas accepté par la direction à ce sujet, cela n'en vaut peut-être pas la peine; vous devriez peut-être en parler avec votre patron.

Si vous décidez de renoncer à enseigner aux développeurs qui ne semblent pas en mesure de le comprendre, mais que vous devez absolument utiliser git à l'avenir, pensez à remplacer toute interaction par les commandes git par cuit- des scripts ou une interface graphique qui enlève toutes les spécificités de git. Versez tout le contrôle des erreurs, etc. dans les scripts, et essayez de le faire fonctionner.

Answer 5

Je voudrais vous référer à ceci entrée de blog de Joel Spolsky .

La raison pour laquelle vous voyez que ces développeurs juniors le découvrent rapidement est très probablement parce qu'ils n'ont pas une notion prédéterminée concernant le fonctionnement du contrôle de version en général, ou du moins pas un modèle mental aussi profondément enraciné. En tant que tels, ils arrivent avec une table rase. Vos programmeurs plus expérimentés tentent probablement d'appliquer les concepts qu'ils connaissent déjà et échouent à cause de cela.

En plus de cela, autant que je n'aime pas le dire; qui lit réellement les manuels d'utilisation? En règle générale, ils sont très mal à expliquer l'utilisation de base. Regardez juste la page de validation de git dans le manuel et considérez combien de nouveaux termes et expressions sont introduits pour quelqu'un qui n'est pas au courant du concept. Sans une bonne introduction, j'aurais probablement renoncé à utiliser Git tout de suite.

Mon conseil personnel serait de commencer à expliquer les commandes:

• git ajouter <fichiers>
• git commit
• git pull
• git Push
• statut git

Les conflits de fusion logique devraient être expliqués ensuite, car ce sera certainement votre premier problème une fois que les gens auront appris à valider du code.

Généralement, des situations surviendront où les gens devront investir plus de temps dans des trucs d'apprentissage (retours, balises, conflits de fusion, branches, rebasage, hooks) mais essayer d'expliquer tout cela avant que cela ne soit nécessaire n'aidera pas les personnes qui ont du mal à entrer le flux.

Pour résumer: D'après mon expérience personnelle, certaines personnes ne passent tout simplement pas beaucoup de temps à explorer de nouvelles techniques, concepts ou outils et elles ont généralement tendance à ramasser les choses que vous leur présentez à un rythme plus lent. Cela ne signifie pas qu'ils sont de mauvais programmeurs ou de mauvaises personnes, mais ils ont généralement un ensemble de compétences plus étroit.

Answer 6

J'ai trouvé stackoverflow très utile pendant que je prenais pour la première fois la terminologie Git. Des questions comme celles-ci m'ont été très utiles (principalement en raison de leur concision) et je les ai gardées ouvertes dans des onglets pendant les deux premières semaines où je l'ai utilisé. Peut-être imprimer quelques réponses en gras? Surtout le schéma du premier.

Quelles sont les différences entre "git commit" et "git Push"?

Quelle est la différence entre 'git pull' et 'git fetch'?

J'ai également trouvé une représentation visuelle du tronc incroyablement utile, mais vous la couvrez déjà avec SourceTree.

_{À part, ce morceau appartient probablement dans un commentaire mais je manque de représentant: je suis l'un des consultants juniors mentionnés dans la question. Avant de commencer, j'avais une idée de ce qu'était un système de contrôle de source et j'avais poussé SVN littéralement deux fois, Gusdor me donne plus de crédit que je ne le mérite. Toute l'équipe avait une formation Git spécialisée de haute qualité, des jouets et du temps pour jouer. Le problème n'est pas lié aux instructions de Gusdor. J'espère qu'il existe une bonne solution alternative à cela afin que je puisse la mettre en signet et en savoir plus.}

Answer 7

Git est une refonte majeure si vous avez appris à faire du contrôle de source sur SVN. Beaucoup des habitudes que vous avez développées là-bas (qui pourraient bien être les meilleures pratiques pour SVN) vous induiront en erreur lorsque vous utilisez git. C'est principalement parce que le modèle de branchement de git est fondamentalement différent. Il ne tire pas parti des dossiers pour les branches, et il est également possible de le rendre non linéaire car il a été conçu pour mieux prendre en charge les cas d'utilisation distribués. Il faut du temps pour désapprendre les habitudes SVN et comprendre comment vous êtes supposé utiliser git.

Commencez simplement

Vous dites que vous avez choisi Gitflow comme standard pour la gestion des succursales. Cela me semble être votre plus grosse erreur.

Pour citer Gitflow considéré comme nuisible :

Toutes ces branches utilisées obligent GitFlow à avoir un ensemble élaboré de règles compliquées qui décrivent comment elles interagissent. Ces règles, associées à l'historique intangible, rendent l'utilisation quotidienne de GitFlow très difficile pour les développeurs.

Pouvez-vous deviner ce qui se passe chaque fois que vous configurez un réseau complexe de règles comme ça? C'est vrai - les gens font des erreurs et les brisent par accident. Dans le cas de GitFlow, cela se produit tout le temps. Voici une courte liste, nullement exhaustive, des erreurs les plus courantes que j'ai observées. Celles-ci sont répétées constamment, parfois tous les jours, souvent maintes et maintes fois par les mêmes développeurs - qui sont, dans la plupart des cas, très compétents dans d'autres domaines logiciels.

Vos développeurs sont probablement dépassés par la complexité de cette norme. Personnellement, je ne pense pas que cela ait un quelconque avantage, et l'article ci-dessus avance le même argument. Mais c'est une discussion séparée. Objectivement, cependant, c'est une norme assez lourde avec beaucoup de gestion manuelle, et cela nécessite beaucoup d'efforts cognitifs.

Vous devez commencer plus simplement. Ne vous inquiétez pas d'une norme de branchement en ce moment. Concentrez-vous sur à les habituer à utiliser git en premier. Vous n'avez vraiment besoin que de quelques opérations pour commencer:

• cloner
• tirer
• branche
• fusionner
• commettre
• Pousser
• savoir comment .gitignore travaux
• peut-être tag

Oui, votre histoire peut sembler un peu désordonnée au début. C'est d'accord. Ne vous en faites pas pour le moment. Obtenez-les en utilisant git .

Augmentez progressivement les connaissances

De là, vous pouvez progressivement les éduquer sur une utilisation légèrement plus avancée.

• Apprenez-leur la commande de la cachette épique
• Apprenez-leur à utiliser la réinitialisation lorsqu'ils veulent abandonner l'engagement local qu'ils viennent de faire
• Apprenez-leur à modifier
• Apprenez-leur à rebaser pour éviter les commits de fusion inutiles
• Apprenez-leur à rebaser interactivement pour organiser leurs commits avant de pousser
• Apprenez-leur comment ils peuvent commander à partir de n'importe quel hachage, tag ou branche

Assurez-vous surtout de profiter des opportunités pour leur montrer des façons plus propres de faire entrer leur code dans le référentiel, mais aussi d'enseigner ce genre de choses dans les activités de formation et ce que vous avez. Avoir un ou deux gourous que les gens peuvent approcher lorsqu'ils ne sont pas sûrs de ce qu'il faut faire aidera aussi beaucoup. Si vous avez quelque chose comme Slack, créez une chaîne dédiée et encouragez les gens à y poser et à y répondre.

Ensuite choisissez une norme de branchement

Une fois que la plupart des entreprises sont compétentes pour utiliser git, , alors vous pouvez consulter les normes de branchement. En choisir un à l'avance est une très mauvaise idée pour plusieurs raisons:

• Ils ne connaissent pas suffisamment l'outil pour vous dire si la norme fonctionne bien pour les cas d'utilisation de l'entreprise
• Ils ne seront pas en mesure de proposer des normes alternatives
• Ils doivent apprendre à la fois l'outil et la norme en même temps
• Certains supposeront que la norme que vous choisissez est la seule façon d'utiliser git
• Ils ne pourront pas identifier les rares cas Edge où la norme fait plus de mal que de bien

Vous ne devriez pas transmettre un flux de travail Git depuis la montagne. Votre équipe doit avoir son mot à dire et être en mesure de vous donner des informations sur le bon déroulement ou non. Ils ne peuvent pas faire cela s'ils ne comprennent même pas encore les principes fondamentaux. Vous n'avez pas besoin de chaque développeur unique pour avoir des connaissances approfondies comme celle-ci, mais vous en avez certainement besoin de plusieurs qui l'obtiennent vraiment. Et vous avez besoin de la grande majorité d'être au moins compétent en git pour qu'ils en sachent assez pour rester un peu sur les rails.

Voici quelques alternatives à Gitflow que votre équipe peut envisager:

• OneFlow
• Workflow de branche de fonctionnalité
• Workflow centralisé

Regardez-les et Gitflow, pesez-les par rapport à vos cas d'utilisation et choisissez celui qui vous convient.

Answer 8

Achetez-leur un livre

Honnêtement, je suis tombé carrément dans le camp que vous décrivez. Je viens d'un milieu de SourceSafe et ClearCase. Au début, Git était complètement impénétrable pour moi, malgré le fait que mon patron ait traversé plusieurs fois.

Ce qui m'a aidé était un livre qui décrivait clairement ce qui se passait, mais plus important encore, comment Git était fondamentalement différent de tout système de contrôle de source que j'avais utilisé auparavant. Maintenant, je préfère Git à tout autre choix.

Malheureusement, je ne me souviens pas quel livre j'avais lu à l'époque, mais assurez-vous simplement que celui que vous obtenez pour eux (ou les pointer vers) se concentre sur la façon dont il est différent et comment il nécessite un état d'esprit différent.

La meilleure estimation pour une recommandation de livre est:

Pro Git par Scott Chacon (lien Amazon pour plus de facilité ... achetez chez qui vous voulez: https://www.Amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Remarque : N'achetez pas un livre de référence pour Git. Cela n'aidera pas du tout.

Answer 9

Je joue avec l'introduction de git où je suis (de TFS), donc votre question me vient à point nommé, d'autant plus que j'ai également eu un peu de recul en abordant le sujet.

Dans Peopleware , les thèses sous-jacentes de l'ensemble du livre sont:

Les problèmes majeurs de notre travail ne sont pas tant technologiques que sociologiques dans la nature .

J'en parle parce que le nôtre n'est pas un problème technique. git, bien qu'un peu obtus, ne dépasse probablement pas les capacités de la vôtre ou de mes développeurs seniors, à moins qu'ils ne soient extrêmement stupides *.

Voyons cela de votre point de vue de développeur, en tant que personnes, pas en tant que machines techniques:

Vous leur demandez de cesser d'utiliser un système de contrôle des sources dont ils ont (probablement) la maîtrise, vers un autre qu'ils n'ont pas. C'est un peu comme demander à un expert git d'arrêter d'utiliser git et de passer à svn n'est-ce pas? Je pense que l'expert git serait ennuyé et ne mettrait probablement pas beaucoup d'efforts dans svn parce que git fonctionne très bien et il y a des parties qu'elle aime vraiment qui sont vraiment difficiles à faire dans svn.

C'est probablement la raison pour laquelle les juniors ont mieux fait - peut-être qu'ils n'ont pas la maîtrise de svn et git est leur chance de l'abandonner ^.

Les seniors se méfient cependant du coût d'opportunité - s'ils apprennent git, alors ils ne le sont pas:

• Learning React/Angular/Swift/Blockchain/Kotlin (une autre chose qu'ils pensent qu'ils devraient apprendre).
• Faire du bricolage/tailler/naviguer/poésie/glockenspiel/tout ce qu'ils veulent réellement faire.
• Passer du temps avec leurs enfants/parents/amis/proches.

• Offrir cette "grande nouveauté" - il y a un délai, un budget, etc. Ils sont probablement inquiets à ce sujet.

  "Je dois faire tout ce qui précède, pourquoi dois-je utiliser git alors que nous avons déjà le contrôle de code source?"

Quelles raisons leur avez-vous données pour passer d'une chose dans laquelle ils sont bons à une autre chose qui est franchement gênante lorsque vous êtes nouveau et qui nécessite une refonte complète de la façon dont vous faites le développement? Avez-vous expliqué les avantages des fonctionnalités de git?

Pull-demandes? Des enregistrements à grain fin? Source distribuée? Forks?

Ont-ils introduit ces raisons? Ce sont des changements structurels massifs si vous êtes dans un état d'esprit de contrôle de source centralisé - pas seulement des changements techniques mais aussi culturels, et nous savons combien il est difficile de changer une culture.

Donc, en gros, réfléchissez à ce que vous demandez à vos développeurs et assurez-vous que c'est pour les bonnes raisons. Si vous voulez juste le faire parce que svn est stupide et vieux et que personne ne l'utilise plus, c'est bien, mais c'est plus difficile à vendre à d'autres qui ne pensent pas comme vous et veulent juste se lancer dans leur journée . Vous devez énoncer les avantages en termes qui ont du sens pour votre équipe et pour le projet. Si vous pouvez leur faire accepter que git en vaut la peine, alors vous n'avez pas à vous soucier de leur apprentissage de la technologie, simplement en acceptant le flux de travail que vous avez configuré.

Bonne chance.

---

_{* Je recommande fortement aux gens de se rappeler que la plupart des développeurs ne sont pas stupides en ce qui concerne les aspects techniques. Jeter cela comme une raison jusqu'à ce qu'il n'y ait pas d'autres explications.}

_{^ et être plus employable, ce à quoi les personnes âgées peuvent ne pas trop penser, surtout compte tenu de l'âgisme qui prévaut dans notre industrie.}

Answer 10

D'après mon expérience, certaines personnes peuvent être à l'aise avec git sans le comprendre. Ils trouvent un didacticiel de base, prennent des commandes de base et ils sont prêts à partir. C'est probablement là que vous, consultants juniors, vous vous en sortez. Je ne crois pas que vous puissiez vraiment apprendre le git en quelques jours!

D'autres personnes ne peuvent pas le faire, elles doivent comprendre ce que fait Git, et cela prend plus de temps. J'étais dans cette catégorie; J'ai trouvé très utile de jouer avec le contenu de .git répertoire, c'est là que les choses ont commencé à cliquer pour moi. Des sessions individuelles avec notre responsable technique ont également aidé.

Vous pouvez faire des tutoriels individuels car les gens apprennent différemment et peuvent être vraiment confus à propos de différentes parties, dans une session individuelle, c'est plus facile à voir et à résoudre. S'ils sont vraiment gênés par le fait qu'ils ne comprennent pas comment git garde la trace des branches, montrez-leur le contenu de .git répertoire, etc.

Answer 11

Je pense qu'il s'agit moins d'une question de génie logiciel que d'une question de psychologie. Je voudrais me référer à Algorithms to Live By: The Computer Science of Humand Decisions. L'auteur y aborde le sujet du compromis explorer/exploiter. Les humains passent généralement par une phase d'exploration puis par une phase d'exploitation (d'utilisation) de ce qu'ils ont exploré. Il y a une théorie mathématique solide derrière pourquoi c'est le cas afin d'obtenir une utilisation optimale de quelque chose dans un certain intervalle.

Cela s'étend également à l'âge et à l'expérience. Les humains voient leur propre vie comme un intervalle, et après une certaine phase d'exploration, il est optimal de commencer à utiliser vos connaissances. Ils ont cité une étude dans laquelle on a demandé aux participants plus âgés s'ils voulaient rencontrer quelqu'un de célèbre qu'ils aiment ou plutôt un membre de la famille. Ils choisissaient généralement le membre de la famille, tandis que les jeunes choisissaient plus probablement la personne célèbre. Cependant, lorsqu'on leur a demandé d'imaginer comment ils décideraient s'ils avaient 20 ans de moins, les personnes âgées choisissaient également la personne célèbre. Ce qui suggère que les gens cessent de construire leurs réseaux sociaux lorsqu'ils croient qu'ils ont moins à explorer qu'à exploiter ce qu'ils savent déjà.

Vos ingénieurs seniors sont probablement plus âgés, ils sont probablement passés par quelques systèmes de contrôle de version. SVN est probablement le meilleur qu'ils aient utilisé jusqu'à présent (au moins en regardant les anciens systèmes de versioning que j'ai utilisés, SVN les a tous battus).

Leur stratégie optimale est d'exploiter SVN, car ils ont fait leur exploration et ont trouvé que c'était le meilleur, qu'ils exploitent maintenant.

C'est la psychologie humaine de base et des centaines de milliers d'années d'optimisation évolutive contre lesquelles vous vous battez.

Vous devrez leur montrer a) combien de temps ils ont une carrière devant eux, les inciter à réfléchir d'un point de vue différent sur l'intervalle sur lequel ils se voient et b) leur demander ce qu'ils pense que c'est super et ce qu'ils manquent dans SVN. Vous pouvez exposer des centaines d'avantages de git, mais ils auront déjà une idée claire pourquoi SVN est le meilleur, après tout, ils ont probablement déjà utilisé 5 systèmes de contrôle de version auparavant. Vous devez trouver la faille dans l'armure de cet argument, puis voir si git peut résoudre ces problèmes, alors ils se seront convaincus.

Answer 12

Ne leur donnez pas d'outil ni d'interface graphique pour utiliser Git. Cela ne fera que confondre les choses. Git a été conçu pour fonctionner sur une ligne de commande, ce qui devrait probablement être l'endroit où il est appris. Toute interface graphique peut avoir ses propres conditions et particularités, s'en tenir à ce qui est simple.

Ensuite, il faudrait examiner certains des problèmes que Git fait mieux que SVN. Pour que votre équipe l'apprenne, vous devez les motiver pour voir pourquoi git est meilleur.

• Possibilité de s'engager sans être connecté au réseau
• Capacité à créer et à jouer avec ses propres branches
• Correctifs pouvant être envoyés entre eux et toujours fusionner la piste
• cueillette des cerises sans douleur.
• changement de base
• trouver des bugs avec git splice

Je suis sûr que SVN a évolué au cours des dernières années, mais ce sont des choses qui causaient un monde de douleur. Si les développeurs voient que ce nouvel outil n'est pas seulement quelque chose de fantaisiste mais qu'il a de solides avantages pour leur travail, ils seront probablement plus enclins à l'appuyer.

C'est une nouvelle chose à apprendre et il y a suffisamment de similitudes pour que cela puisse prêter à confusion, mais en 2017, DCVS est à peu près une compétence essentielle pour chaque développeur.

Answer 13

Dites-leur de ne pas s'inquiéter

À Git, une fois le travail engagé, il est presque impossible de perdre. Le seul travail que vous pouvez facilement perdre est un travail qui n'a pas encore été engagé.

Montrez-leur comment git reflog travaux. Ils n'ont pas besoin de savoir comment l'utiliser; ils ont juste besoin de savoir qu'il est là, afin qu'ils puissent obtenir de l'aide pour récupérer leur travail si quelque chose ne va pas.

Ensuite, imposez-leur cette règle simple: en cas de doute, engagez-vous. Ils peuvent toujours annuler la validation plus tard (même à distance!).

N'utilisez pas d'interface graphique

Une interface graphique leur donnera un démarrage plus rapide, mais ils ne comprendront jamais vraiment Git. En outre, j'ai trouvé que c'est pas "presque impossible de perdre" le travail engagé lors de l'utilisation d'une interface graphique Git. J'ai vu des interfaces graphiques faire des choses horribles comme présenter une liste de contrôle lors de la fusion, puis, si l'utilisateur décoche un élément, effacer ce fichier de l'historique sans avertissement ni enregistrement. Une interface graphique est bien pire que d'apprendre simplement Git en ligne de commande.

Le code de programme de paire valide

Apprentissage git add -A suivi par git commit ne devrait pas être trop difficile, mais en particulier lors de la fusion (ou du rebasage) avec la télécommande, ils auront besoin d'aide. Indiquez clairement que n'importe qui est le bienvenu pour demander de l'aide à tout moment. Attendez pendant qu'ils tapent les commandes et prennent des notes. Au fil du temps, ils augmenteront progressivement le nombre de situations qu'ils peuvent gérer sans aide.

Git est déjà sûr

Quelqu'un ci-dessus a parlé d'avoir "un endroit sûr pour jouer". Mais Git est cet endroit sûr. Il n'y a que deux cas normaux et quotidiens où il est facile de perdre du travail:

• Code non validé
• Utilisation d'une interface graphique

Assurez-vous qu'ils s'engagent tôt et souvent, et qu'ils ne pas commencent par le mauvais chemin avec une interface graphique, et ils verront bientôt qu'ils peuvent faire confiance à Git avec leur code encore plus que tout autre contrôle de source systèmes dans le passé.

Answer 14

Je conseillerais de regarder Gitless . C'est un wrapper sur git qui simplifie beaucoup le flux de travail de base (pas besoin de se soucier d'une zone de transit, les branches gardent leurs propres copies de travail des fichiers, les utilisations plus simples de git rebase sont traités avec gl Fuse, etc.) tout en conservant un référentiel git sous-jacent pour la collaboration ou si vous devez faire quelque chose d'inhabituel. De plus, les messages sont un peu plus adaptés aux novices. Et les commandes sont suffisamment proches pour que git agisse comme un tremplin si elles ont besoin d'utiliser un système sans gitless pour quelque raison que ce soit.

Answer 15

J'ai essayé de documenter les bases de l'utilisation de la ligne de commande de git. C'était toujours déroutant - à la fois pour moi (qui avait de l'expérience avec Perforce et Source Safe), et pour les programmeurs qui préféraient l'ancien paradigme "juste Zip les dossiers pertinents". C'était inquiétant de voir un outil opaque modifier le contenu de mon répertoire de travail, et souvent d'avoir à discuter avec l'outil pour incorporer des changements particuliers dans mon répertoire de travail.

Au lieu de cela, j'utilise deux types d'indirection.

• J'utilise GitKraken pour fournir un historique visuel de mes branches et une interface graphique qui masque les instructions de ligne de commande. GitKraken gère les interactions entre le référentiel distant "Origin" et ce que git pense être mon répertoire de travail local.

• Je garde également un "vrai" répertoire de travail local qui est distinct de ce que git pense être mon répertoire de travail local. Je synchronise manuellement ces deux répertoires de travail, ce qui me permet d'être bien plus à l'aise que toute modification de mon répertoire de travail correspond à ce que j'avais l'intention d'avoir.

Answer 16

Puis-je faire quelque chose pour aider ces employés à apprendre Git?

Êtes-vous sûr que le problème est Git et pas autre chose? Ce que j'obtiens de ce commentaire est que la direction a décidé de changer quelque chose sans obtenir l'adhésion des contributeurs principaux et charge quelqu'un de subalterne de diriger le changement. Cela semble être un bon point de départ pour l'échec, quel que soit le changement. La complexité de Git n'est pas un problème, le problème est qu'un changement dont ils ne ressentent pas le besoin leur est imposé.

Donc, ne vous concentrez pas sur la façon de leur enseigner Git, tant qu'ils ne voient pas d'avantage pour le commutateur qu'ils vont traîner les pieds. Montrez-leur comment Git est une solution aux problèmes qu'ils rencontrent actuellement. Pas comment Git peut leur fournir des choses dont ils ne ressentent pas encore le besoin, ni comment Git fournit une solution aux problèmes des autres personnes, comment Git résout les problèmes qu'ils combattent maintenant. Leur enseigner Git ne sera plus un problème.

Answer 17

Souvent, Git est utilisé dans une entreprise pour résoudre des problèmes avec les succursales. Oui, c'est mieux dans les branches que dans Subversion, mais ça ne fait pas de magie.

Il est très probable que les développeurs expérimentés ont travaillé dans de nombreuses entreprises qui l'ont fait.

• Création de succursales car la direction n'est pas disposée à décider entre des demandes contradictoires
• Avoir utilisé une branche pour chaque client plutôt que des commutateurs de configuration.
• Avoir dû avoir une branche de correction de bogues pour chaque client car la direction n'était pas disposée à obliger tous les clients à passer à la même version du logiciel
• Etc.

Par conséquent, dès que certains me disent qu'un outil est bon pour ramifier mon esprit me dit.

La direction ne veut pas décider de la direction de l'entreprise et préfère que je gaspille la vie à devoir fusionner mon travail dans 101 branches différentes, tout en devant tester 101 versions différentes du logiciel.

De plus, le concept selon lequel deux personnes travailleraient sur le même fichier en même temps est "bon", n'est tout simplement pas acceptable pour quelqu'un qui a expérimenté un projet bien géré, donc la promotion de Git en tant qu'outil pour le faire, est peu susceptible d'être expérimentée les développeurs qui vous aiment.

Chaque fois que je regarde l'histoire dans Git, il est très difficile de voir pourquoi le code a changé, car 50% ou plus de l'histoire est une fusion qui n'aurait logiquement jamais dû être publique et qui devient vide de sens dès que le code quitte les développeurs machine.

Mais j'aimerais travailler quelque part où:

• Aucun code ne pénètre dans le système central tant qu'il n'a pas été compilé et testé sur un serveur de confiance.
• Il existe un moyen simple de suivre les révisions de code
• Où chaque fois que je fais un "get", le code compile et fonctionne toujours
• Où je peux pousser mes changements sans avoir à faire de course avec quelqu'un d'autre, ou à m'égarer au bureau pour voir si j'ai cassé la version.

Alors résolvez les vrais problèmes et si Git fait partie des solutions que vos développeurs expérimentés achèteront, mais ne vous attendez pas à ce qu'ils aiment Git simplement parce que c'est un jouet cool qui peut faire des "fusions magiques".

Par conséquent, partout où un développeur peut pousser de son Git local vers le Git central le fait mal, un processus automatisé contrôlé devrait prendre les modifications des développeurs et après les avoir testés, etc. succursales, etc. qui ne présentent pas d'intérêt à long terme.

Je m'attends à ce que Kiln ( http://www.fogcreek.com/fogbugz/devhub ) ou même GitHub en utilisant un flux de travail "pull request" garderait les développeurs expérimentés heureux , par exemple ne commencez pas avec le niveau bas pris, commencez par le processus amélioré.