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

68

Le contexte

Mon équipe de 8 ingénieurs est actuellement en train de passer à Git (de Subversion) pour notre prochain grand projet. Nous avons une poignée d'ingénieurs «plus expérimentés» qui ont du mal à trouver Git. On me pose les mêmes questions triviales malgré le fait que j'ai fourni des manuels d'utilisation, des activités de formation et des sessions de tableau blanc. Nous avons eu deux consultants juniors qui ont tout ramassé en quelques jours et cela a vraiment éclairé la question. Ce modèle n’est pas limité à Git mais il est devenu visible en conséquence.

Question

Je ne suis pas particulièrement favorable aux ingénieurs qui ne peuvent pas / ne veulent pas apprendre - en particulier au personnel possédant le niveau 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 je sens que toute la nouvelle terminologie les déconcerte.

Est-ce que je peux faire quelque chose pour aider ces employés à apprendre Git?

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

Gusdor
la source
1
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
maple_shaft
3
La simple logique binaire de fire vs keep peut fonctionner pour des ordinateurs, mais pas pour des personnes. Vous voudrez peut-être consulter le site lieu de travail.stackexchange.com pour répondre à votre question une fois que vous vous sentirez prêt à y répondre au-delà de l'aspect Git.
Frank
Signalez
1
C'est vraiment un problème de personnes / psychologie, pas un problème d'ingénierie logicielle.
Jesper
@Jesper oui et non. J'allais le mettre sur le lieu de travail, mais je voyais le potentiel pour un conseil très spécifique à Git (que j'ai reçu!) Qui pourrait être immédiatement applicable.
Gusdor

Réponses:

148

Donnez-leur un jouet.

Git est difficile. Surtout si vous avez fait du contrôle de source dans un paradigme différent. J'ai cassé la construction la première fois que j'ai essayé de travailler avec git. Cela me rendait tellement paranoïaque que je ne voulais pas faire l'enregistrement tant que tout n'était pas terminé. Je cachais des versions dans des dossiers. Ensuite, j'ai enfin compris ce dont j'avais besoin pour passer outre:

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

Une fois que j'ai eu cela, je posais intentionnellement des problèmes pour que je puisse apprendre à les résoudre, le tout dans mon lieu sûr. J'ai développé un motif que je pourrais utiliser même si je m'interrompais et que je retrouvais tout de même un bon état. Avant longtemps, les gens venaient me voir pour demander de l'aide avec git. Tout ça parce que j'ai pris le temps de jouer avec un jouet.

Si vous les jetez au plus profond, vous aurez de la chance s'ils parviennent à flotter.

confits_orange
la source
36
J'aime cette réponse, mais à mon sens, cela soulève une autre question: comment les motivez-vous pour jouer avec ce jouet quand ils sont "trop ​​occupés à faire un vrai travail"?
David Arno
18
Donnez-leur crédit pour le faire si vous devez. Distribuez des certificats «qualifiés Git» si vous pensez pouvoir vendre cela. Mais sérieusement, si cela ne les intéresse pas naturellement, vous avez de plus gros problèmes que Git. Tous les développeurs devraient pouvoir utiliser les outils de développement.
candied_orange
48
@DavidArno Dites à chacun de passer une heure par jour dessus, quel que soit son travail. Ou même deux heures. Pouvoir utiliser le contrôle de source correctement est essentiel pour un projet. Apprendre ces outils est un "vrai travail".
coinbird
16
'Comment les motivez-vous à jouer avec ce jouet quand ils sont «trop occupés à faire du vrai travail»? '- C'est du vrai travail.
David
18
Je suis dérouté. Personne n'a mentionné le xkcd obligatoire !
GnP
32

Le développeur moyen n'a pas besoin de beaucoup de goodies git. Il s’agit d’un système de contrôle de sources distribué, mais la plupart des équipes l’utiliseront avec un dépôt central canonique sur lequel pousser et tirer.

Les commandes principales dont votre équipe aura besoin sont:

  • extraire et fusionner les modifications à distance et gérer les conflits qui en résultent (éventuellement une nouvelle base)
  • commit et envoie les commits à distance (ou pousses vers le dépôt intermédiaire / branche pour transférer les modifications dans le fichier principal après révision)
  • Pour obtenir de l'aide, corrigez les dégâts après avoir mal agi.

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

  • gérer les commits locaux
  • gérer les branches

Pour ceux qui ne sont pas familiers avec git et ceux qui ne veulent pas apprendre, configurez quelques commandes avec alias 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 l’esprit de la bande dessinée xkcd , il suffit de mémoriser les commandes et d’espérer que les choses ne se dérangent pas trop quand elles le demandent à un professionnel.

monstre à cliquet
la source
8
Il utilise le flux de travail gitflow. Par conséquent, la gestion des branches ne doit pas être considérée comme un sujet avancé. Elle fait partie de la commande principale que ses développeurs doivent comprendre. En général, Git considère la gestion de branche comme quelque chose de fondamental plutôt que de avancé.
Slebetman
5
@slebetman: Donner un nom ne le rend pas moins compliqué ou difficile.
Robert Harvey
3
Vous parlez de "gérer les commits locaux" comme un élément nécessaire aux utilisateurs plus avancés. Théoriquement, la gestion des versions sur votre propre ordinateur devrait être un cran plus bas dans l’échelle de difficulté que la gestion des versions dans un dépôt distant, partagé avec d’autres codeurs.
Tulains Córdova
Peut-être que si vous travaillez quelque part avec un gestionnaire de version à temps plein, vous n'avez pas à vous soucier des branches, mais ailleurs, les développeurs devraient pousser les fonctionnalités vers une branche de test à chaque cycle, en fusionnant des correctifs hautement prioritaires de la branche de test à la développement, et la mise en production des versions de la branche de test.
Brian Gordon
@ RobertHarvey: La ramification n'est ni compliquée ni difficile. C'est basique. Le flux de travail de gitflow est compliqué dans les cas critiques comme les versions de correctif, mais le cas d'utilisation courant est simple.
Slebetman
28

Demandez-leur d'utiliser une interface utilisateur Git.

Si 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 formidable. Nous avons plusieurs QA non développeurs qui ont été en mesure de maîtriser facilement des tâches complexes dans Git grâce à SourceTree.

BlueRaja - Danny Pflughoeft
la source
4
+1 pour SoruceTree. Pour un projet universitaire d'environ 30 étudiants, j'ai dirigé une transition de Subversion à Git en utilisant SourceTree. Les gens se sont adaptés assez rapidement une fois qu'ils ont appris les bases et nous avons eu beaucoup de liens vers de la documentation. J'ai également encouragé les expériences dans les branches de test. Je dirais qu'environ 75% des personnes étaient à l'aise à l'utiliser à la fin du semestre et que certaines avaient même commencé à utiliser la ligne de commande.
Dewick47
5
Lui dire d'utiliser une interface graphique, il a déjà dit qu'il utilise ne répond pas à la question.
WGroleau
9
Le message original a été modifié pour inclure que SourceTree était utilisé après la publication de cette réponse.
Dewick47
7
Je vais aussi suggérer GitKraken. C'est ce que j'avais l'habitude de présenter à Git à certains de mes partenaires du projet CS capstone. Ils l'ont récupéré en 15 minutes - c'est d'une simplicité déconcertante, et son interface est belle et intuitive. Et non, je ne suis pas avec le marketing GitKraken.
Chris Cirefice
2
git guiet gitkvenir avec git lui-même, et je les ai trouvés beaucoup plus faciles à apprendre que les outils en ligne de commande. Si vous êtes naturellement orienté ligne de commande, les interfaces graphiques simples sont parfaitement adaptées aux bases, et vous pouvez effectuer git rebasedes tâches plus complexes à partir de la ligne de commande.
Peter Cordes
25

Cette réponse tente de déterminer comment intéresser les programmeurs expérimentés git, et non comment apprendre gitle moyen le plus rapide. Pour cela, l'excellent livre git est excellent, ou toute quantité de tutoriels (=> Google). Les bons liens qui vont avec cette réponse sont Git est une structure de données purement fonctionnelle ou en particulier le court Comment git stocke vos données .

J'ai peur d'avoir une vue plutôt sombre sur ce sujet. J'ai été exactement à votre place - je suis un gitgeek et je voulais transformer une équipe svnavec des résultats minuscules, avouons-le. Dans mon cas, cela m'a amené à changer activement ma propre perception et à accepter que les gens ne puissent tout simplement pas être "forcés au bonheur". Les gens ne sont pas des ordinateurs, il est incroyablement difficile de les programmer. Je suis toujours heureux d'avoir essayé, cela m'a montré d'une manière plutôt douce ce que je fais et ce que je ne veux pas faire dans ma vie professionnelle.

Il y a des gens qui commencent à être motivés lorsque de nouvelles choses sont impliquées, et il y a ceux qui sont démotivés. Cela n'a rien à voir avec cela git, mais gitvous avez toujours pour effet spécifique "Pourquoi devrions-nous l'utiliser du tout si svntout va bien?", Ce qui constitue un obstacle psychologique énorme.

De plus, le fait de rigoler gitnécessite un intérêt intense pour les structures de données abstraites. Cela peut sembler incroyable, mais selon mon expérience, il existe des programmeurs qui n'ont aucun intérêt et qui s'ennuient et sont surchargés par des éléments plus complexes que de simples tableaux. Vous pouvez vous disputer pour savoir si ces personnes devraient faire le travail qu'elles font, mais c'est ce que c'est.

Si les gens ne s'intéressent pas à cela, 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, de ne pas manquer d'intelligence.

Cela étant dit, il s’agirait ici d’un programme d’application, basé sur une accumulation de connaissances de bas en haut. Cela n'a pas fonctionné pour moi, mais vous pouvez l'inspirer pour lancer le vôtre.

Interface graphique

Bien que l'approche suivante n'ait pas nécessairement besoin de la prise en charge de l'interface graphique pour les actions ( git adddans un référentiel hello world ...), il est extrêmement utile de disposer d'une interface graphique permettant de visualiser le référentiel, dès le début. Si vous ne pouvez pas choisir lequel utiliser, prenez-le gitken dernier recours. Si vos gars utilisent n’importe quel type d’éditeur visuel, trouvez leur gitcomposant graphique.

La structure de données (statique) est la clé

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 problème à 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 ajouter des choses tout le temps. Vous pouvez faire une séance de jeu dans un dépôt local fraîchement créé et utiliser git cat-filepour examiner les objets réels pour leur montrer qu'ils sont en fait aussi trivial que la publicité.

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 gitsous-commandes "massent" ces objets d'une manière ou d'une autre, avec des opérations presque triviales (en fait, il n'y en a qu'un: ajoutez un nouveau commit quelque part), et ...
  • ... tout peut facilement être vu juste en face de vous avec lset git cat-file...

alors ils auront la traduction mentale de ce qui est réellement dans le référentiel. À ce stade, les sénateurs se souviendront peut-être que leurs composants internes svnsont magiques (ils ont déjà eu des problèmes de verrous à l'intérieur du référentiel svn, ou de "réintégration" de branches et autres?), Ce qui peut les motiver un peu.

L’un des problèmes, en particulier chez les personnes habituées svn, est de s’habituer à l’idée qu’un commit (l’objet, et non l’action) est toujours l’arborescence de répertoires complète. En svn, les gens sont habitués à 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 pour une action n'aide pas non plus.

L’autre problème pour les svngars est qu’il svnutilise une histoire linéaire, pas un arbre. C'est encore une fois très différent. Donc , il est temps de souligner ces différences beaucoup .

Actions expliquées en termes de structure

Une fois qu'ils ont compris de quelles parties le gitréférentiel est composé, il est temps de leur montrer exactement ce que font les gitsous-commandes individuelles .

Je parle de add, commiten conjonction avec le répertoire de travail local et l’étape (assurez-vous qu’ils comprennent que le répertoire de travail n’est pas identique à la zone de transfert, ce qui n’est pas le même que le référentiel).

Une fois qu’ils ont compris que ces commandes ne faisaient que développer l’arbre (qui, à ce stade, consiste en 3 types: blobs, arbres, commits, pas seulement commets), vous pouvez faire un premier git pushet git pull(en mode avance rapide!). ) pour leur montrer que, gitlittéralement, ils ne déplacent que leurs objets, que les hachages ne sont en réalité que des hachages de contenu, que vous pouvez facilement copier ces éléments avec une commande de copie du système de fichiers, etc.

Évidemment, restez loin de toute option non essentielle de ces commandes, nous parlons git add hello.txtici.

Branches

Notez que la création de branches est particulièrement difficile pour les svnutilisateurs, car elle est totalement différente. Le svnmodèle est beaucoup plus facile à visualiser car il n’ya fondamentalement rien à visualiser - il est bien visible. Le gitmodèle pas tellement. Assurez-vous qu'ils savent dès le départ que les branches et les balises ne sont que des "notes autocollantes" pointant quelque part, et n'existent pas réellement en termes d'histoire statique et immuable.

Puis, exemple par exemple, montrez ce que vous pouvez réellement faire avec eux. Comme vous semblez être habitué git, vous ne devriez pas avoir de difficulté à y trouver une motivation. Assurez-vous qu'ils voient toujours cela en termes de croissance de l'arbre.

S'ils ont cela, vous pouvez expliquer comment git pullc'est vraiment git fetch && git merge; comment tous les référentiels contiennent exactement les mêmes objets ( git fetchc'est presque la même chose que copier du contenu scpdans le répertoire des objets git) et ainsi de suite.

Probablement, si à ce stade-ci vous n’avez pas réussi à éveiller leur intérêt, vous pouvez tout aussi bien abandonner, mais s’ils parviennent à aller aussi loin, ils disposeront de tous les outils mentaux à leur disposition, et il devrait y avoir peu peur impliquée plus. Le reste (workflow git ...) devrait alors être en descente.

Derniers mots

Cela ressemble à beaucoup d'effort, et c'est vraiment. Ne vendez pas ceci comme "nous en avons besoin pour ce projet" mais "cela vous aide à vous développer personnellement et vous aidera dans toutes vos interactions ultérieures". Vous avez besoin de beaucoup de temps pour cela, et le temps, c'est de l'argent. Si la direction ne l'accepte pas, cela pourrait ne pas en valoir la peine; vous devriez peut-être en parler avec votre patron.

Si vous décidez de ne plus enseigner aux développeurs qui ne semblent pas en mesure de le comprendre, mais que vous devez absolument utiliser gità l'avenir, envisagez de remplacer toutes les interactions par des gitcommandes par des scripts élaborés ou une interface graphique qui gitsupprime tous les détails. Versez tout le contrôle d'erreur, etc. dans les scripts, et essayez de le faire fonctionner.

AnoE
la source
11
Peut-être vrai, mais le problème avec cette approche est que la plupart des programmeurs ne veulent pas passer des jours à comprendre les détails de leur contrôle de code source. Ils veulent simplement que cela fonctionne, tout simplement. . OMI, git échoue à cela. Il est assez difficile de comprendre comment fonctionne votre code pour se préoccuper des blobs.
user949300
1
Votre commentaire est vrai à 100%, @ user949300, d’où mon conseil pour remplacer gitpar de la super-porcelaine à ne pas utiliser git, de manière efficace. Le PO devrait l'adopter (y compris le temps requis) en fonction de ses activités. Comme je l'ai écrit, je n'ai pas réussi avec cette approche (ni avec une autre) à amener tout le monde "dans le giron", mais néanmoins, si j'étais (obligé) d'essayer à nouveau, ce serait encore mon approche.
AnoE
1
Franchement, je pense que vous pouvez aller assez loin en utilisant git sans vraiment comprendre comment cela fonctionne. Si vous connaissez une branche, ajoutez, poussez et tirez, il y a environ 95% de ce que la personne type utilisera jamais.
Casey
6
@ user949300 "Days" ne correspond pas du tout à mon expérience d'apprentissage de Git. Git dispose de la meilleure documentation que j'ai jamais vue sur un projet. Passez une heure à lire les 3 premiers chapitres de Pro Git , qui est écrit dans un format très accessible avec de nombreux diagrammes. Un rapide "comment je ___ dans Git" sur Google fournit presque invariablement le reste - généralement à partir d'une réponse Stackexchange.
Jon Bentley
1
@Gusdor et al, gardez à l'esprit que cette réponse est spécifique à cette question: comment inciter les programmeurs expérimentés à en apprendre davantage git? Bien entendu, toutes les autres ressources (excellente documentation git, tutoriels, etc.) sont également valables. Gusdor, si vous voulez en savoir plus, allez sur Google "objets git" ou "structures de données git" et vous trouverez rapidement une mine d'informations. J'ai ajouté quelques liens dans la réponse. Vous pourriez même demander à l'une des personnes âgées de faire une séance d'information sur ce sujet. ;)
AnoE
14

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

La raison pour laquelle ces développeurs débutants décident de s’y prendre rapidement est très probablement due au fait qu’ils n’ont pas de notion prédéterminée concernant le fonctionnement du contrôle de version en général, ou du moins qu’il n’en a pas un modèle mental aussi profondément enraciné. En tant que tels, ils arrivent avec une ardoise vierge. Vos programmeurs les plus expérimentés essaient 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 général, ils expliquent très mal l’utilisation de base. Il suffit de regarder la page de validation de git du manuel et de déterminer combien de nouveaux termes et expressions sont présentés à quelqu'un qui n'est pas au courant du concept. Sans une bonne introduction, j'aurais probablement abandonné l'utilisation de Git sur-le-champ.

Mon conseil personnel serait de commencer à expliquer les commandes:

  • git add <fichiers>
  • git commit
  • git pull
  • git push
  • statut git

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

Il arrivera généralement des situations dans lesquelles les gens devront investir plus de temps dans l'apprentissage (restitutions, balises, fusions de conflits, branches, rebasages, crochets), mais essayer d'expliquer tout cela avant que cela ne soit nécessaire n'aidera pas les personnes qui ont du mal à entrer dans le flux.

Pour terminer, d’après mon expérience personnelle, certaines personnes ne passent tout simplement pas beaucoup de temps à explorer de nouvelles techniques, de nouveaux concepts ou outils et tendent généralement à saisir 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 des compétences plus étroites.

Robzor
la source
1
"qui lit réellement les manuels d'utilisation?" Je pense que cela pourrait constituer une attente raisonnable pour les plus jeunes développeurs débutants, mais je pense que l'une des compétences que les développeurs devraient acquérir au fil du temps est la lecture de documentation. C'est une compétence à développer, car le langage de la documentation n'est pas le même que celui des tutoriels ou du contenu technique plus informel, et parce qu'il n'est pas toujours aussi évident que les différentes parties de la documentation interagissent. Cela ne devrait pas poser autant de problèmes avec "une poignée d'ingénieurs" plus expérimentés "".
Joshua Taylor
2
Le lien de votre entrée de blog m'a fourni une vidéo YouTube sans rapport.
WGroleau
2
Je trouve que git statusc'est vital, en plus des quatre commandes que vous avez notées.
user949300
1
@JoshuaTaylor Je n'avais pas l'intention de dire que les manuels sont mauvais, ils sont en fait géniaux. Cependant, imaginez que vous référencez quelqu'un à homme et que vous vous contentiez de dire; Allez, c'est facile à apprendre, il suffit de lire les pages de manuel. Ce que je dis, ce n’est pas que la documentation n’est pas géniale, mais qu’une grande partie est impeccablement écrite et utile pour les personnes qui connaissent le domaine pour lequel elle est écrite, mais qu’elle est généralement inutile pour ceux qui recherchent un usage élémentaire. EDIT : Et ce dernier point est apparemment le problème du PO.
Robzor
@ user949300 Bonne prise, je suis tout à fait d'accord.
Robzor
11

Git est une refonte majeure si vous avez appris à contrôler le code source sur SVN. Beaucoup des habitudes que vous avez développées là-bas (ce qui pourrait bien avoir été la meilleure pratique pour SVN) vous induiraient en erreur lors de l'utilisation de git. Ceci est principalement dû au fait que le modèle de branchement de git est fondamentalement différent. Il n'utilise pas les dossiers des branches, mais 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 un certain temps pour désapprendre les habitudes de SVN et comprendre comment vous êtes censé utiliser git.

Commencez simple

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

Pour citer Gitflow considéré comme nocif :

Toutes ces branches utilisées forcent GitFlow à avoir un ensemble complexe de règles compliquées décrivant leur interaction. Ces règles, associées à l'historique immatériel, 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 ensemble complexe de règles de ce type? C'est vrai - les gens font des erreurs et les cassent par accident. Dans le cas de GitFlow, cela se produit tout le temps. Voici une courte liste, non exhaustive, des erreurs les plus courantes que j'ai observées. Celles-ci sont répétées constamment, parfois tous les jours, souvent encore et encore, par les mêmes développeurs - qui, dans la plupart des cas, sont très compétents dans d'autres domaines du logiciel.

Vos développeurs sont probablement dépassés par la complexité de cette norme. Personnellement, je ne pense pas que cela présente un avantage, et l'article ci-dessus avance le même argument. Mais c'est une discussion séparée. Objectivement, il s'agit d'un standard assez lourd avec beaucoup de gestion manuelle et un effort cognitif important.

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

  • cloner
  • tirer
  • branche
  • fusionner
  • commettre
  • pousser
  • connaissances sur le .gitignorefonctionnement
  • peut-être tag

Oui, votre histoire pourrait sembler un peu en désordre au début. C'est d'accord. Ne t'en fais pas pour le moment. Obtenez-les simplement avec git .

Augmenter progressivement les connaissances

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

  • Apprenez-leur la commande épique stash
  • Apprenez-leur comment utiliser reset quand ils veulent jeter le commit local qu'ils viennent de faire
  • Apprenez-leur à modifier
  • Apprenez-leur à rebaser pour éviter les commits de fusion inutiles
  • Apprenez-leur à se rebaser de manière interactive pour organiser leurs commits avant de pousser
  • Apprenez-leur comment ils peuvent payer à partir de n'importe quel hash, tag ou branche

Assurez-vous en particulier de saisir les occasions qui s’offrent à eux pour leur montrer des moyens plus propres d’intégrer leur code dans le référentiel, mais aussi pour enseigner ce contenu dans le cadre d’activités de formation et autres. Avoir un gourou ou deux que les gens peuvent approcher quand ils ne savent pas quoi faire aidera beaucoup aussi. Si vous avez quelque chose comme Slack, créez un canal dédié et encouragez les gens à poser des questions et à y répondre.

Puis choisissez un standard de branchement

Une fois que vous avez la plupart de l'entreprise compétente en utilisant git du tout, alors vous pouvez regarder 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 savoir si la norme convient aux cas d'utilisation de l'entreprise.
  • Ils ne seront pas en mesure d'offrir des normes alternatives
  • Ils doivent apprendre à la fois l'outil et la norme
  • Certains penseront que le standard que vous choisissez est la seule façon d'utiliser git
  • Ils ne pourront pas identifier les cas rares 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 pouvoir vous dire si cela va bien 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 connaissances approfondies de la part de chaque développeur, mais vous avez certainement besoin de plusieurs personnes qui l'obtiennent vraiment. Et vous avez besoin que la grande majorité soit au moins compétente en git pour en savoir assez pour rester un peu sur les rails.

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

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

jpmc26
la source
2
+1 pour avoir mentionné des alternatives à Gitflow. D'après mon expérience, les ateliers de développement essaient beaucoup de souffrir lorsqu'ils tentent de l'adopter lorsque leurs besoins sont excessifs et / ou qu'ils ne l'utilisent pas correctement. Un modèle plus simple est presque toujours préférable dans ces cas et présente l'avantage supplémentaire de rendre Git beaucoup plus facile à apprendre.
Thunderforge
5
@Thunderforge Je ne suis pas d'accord avec ce que l'on appelle "exagération", car cela suggère qu'il est en quelque sorte plus puissant, plus flexible ou plus avantageux. Je ne crois vraiment pas que Gitflow présente des avantages. Cela semble être un pas en arrière: essayer de prendre des workflows complexes nécessaires dans d’autres outils de contrôle de version comme SVN et d’utiliser Git de la même manière. Cependant, Git dispose de la flexibilité nécessaire pour permettre des flux de travail plus simples en premier lieu. Je pense que l’appel est que cela donne l’illusion de devoir penser moins (règles et instructions) sans livrer. Mais votre point est pris. Je vous remercie.
jpmc26
4
Je suis d'accord avec votre approche. Nous nous sommes convertis à Git à partir de SVN il n'y a pas si longtemps. Nous avons donné aux autres développeurs une liste de commandes qu'ils DEVRAIENT utiliser, une liste de commandes qu'ils NE DEVRAIENT PAS utiliser sans aide et une liste de commandes qu'ils NE DEVRAIENT JAMAIS utiliser (du moins pas sans l'aide des experts locaux de Git). Nous avons donné plusieurs formations sur les bases du fonctionnement de Git et de son utilisation. Au cours de plusieurs mois, notre équipe s’y est lentement habituée. Maintenant, nous avons seulement des problèmes occasionnels avec des développeurs devenant confus.
Kyle Un
1
@Gusdor Votre question dit "en transition". Qu'est-ce que ça veut dire? En outre, si Gitflow n’obtient pas l’adhésion, il est peu probable qu’il réussisse, tant il est lourd, que vous pensiez qu’il présente des avantages ou non.
jpmc26
2
@Gusdor Mon conseil est que vous devrez peut-être développer vos compétences en enseignement. Vous devez mieux identifier la cause première d'un malentendu ou d'informations manquantes. Vous devez être capable de comprendre où le raisonnement de quelqu'un va mal. Pour rédiger une documentation, vous devez non seulement être capable de la comprendre, mais également d’être en mesure de prévoir où les gens vont se perdre et ce qui les fera cesser d’essayer de l’utiliser.
jpmc26
11

J'ai trouvé stackoverflow très utile lorsque j'ai commencé à comprendre la terminologie Git. Des questions comme celles-ci m'ont été vraiment utiles (principalement en raison de leur concision) et je les ai laissées ouvertes dans les onglets pendant les deux premières semaines où je les ai utilisées. Peut-être imprimer quelques réponses en gras? Surtout le diagramme sur le 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é qu'une représentation visuelle du tronc était incroyablement utile, mais vous couvrez déjà celle-ci avec SourceTree.

À part cela, cela fait probablement partie d'un commentaire, mais il me manque le représentant: je suis l'un des consultants débutants mentionnés dans la question. Avant de commencer, j'avais une idée de ce qu'était un système de contrôle de code 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 ne vient pas des instructions de Gusdor. J'espère qu'il existe une bonne solution de rechange à cette solution afin que je puisse ajouter un signet et en savoir plus.

SBaker
la source
Grands liens. Je vais voler cette image de flux de données!
Gusdor
9

Achetez-leur un livre

Honnêtement, je suis tombé carrément dans le camp que vous décrivez. Je viens d'un fond de SourceSafe et ClearCase. Au début, Git était complètement impénétrable pour moi, malgré les critiques répétées de mon patron.

Ce qui m'a aidé, c'est un livre décrivant clairement ce qui se passait, mais surtout, en quoi 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 du livre que j'avais lu à l'époque, mais assurez-vous simplement que celui que vous recevez pour eux (ou que vous leur montrez dessus) se concentre sur la façon dont c'est différent et sur la façon dont cela nécessite un état d'esprit différent.

La meilleure estimation pour une recommandation de livre est:

Pro Git by 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 de livre de référence pour Git. Cela ne va pas aider du tout.

Reginald Blue
la source
6
Pro Git est définitivement la solution idéale pour IMO. Vous pouvez l' obtenir gratuitement sur le site Web de Git . Pas besoin de payer pour cela, sauf si vous voulez vraiment une copie papier.
Jon Bentley
4

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

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

Vous pouvez faire des tutoriels individuels car les gens apprennent différemment et peuvent être très confus au sujet de différentes parties. Dans une session individuelle, il est plus facile de voir et de résoudre. S'ils sont vraiment dérangés par le fait qu'ils ne comprennent pas comment git garde la trace des branches, affichez-leur le contenu du .gitrépertoire, etc.

Akavall
la source
4

Je tente de présenter gitoù je suis (de TFS), alors votre question me convient tout particulièrement, surtout que j’ai eu quelques réticences lorsque j’ai abordé le sujet.

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

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

J'en parle parce que le nôtre n'est pas un problème technique. gitBien qu’un peu obtus, ce n’est probablement pas au-dessus de vos capacités ou de celles de mes principaux développeurs, à moins qu’ils ne soient extrêmement stupides *.

Examinons cela du point de vue de vos développeurs, en tant que personnes et non en tant que machines techniques:

Vous leur demandez de cesser d'utiliser un système de contrôle de code source qu'ils maîtrisent (probablement), pour un système qu'ils ne maîtrisent pas. C'est un peu comme demander à un gitexpert de cesser d'utiliser gitet de passer à svnn'est-ce pas? Je pense que l’expert git serait agacé et ne ferait probablement pas beaucoup d’efforts svncar cela gitfonctionne très bien et il ya des parties de celle-ci qu’il aime vraiment qui sont très difficiles à faire svn.

C'est probablement pourquoi les juniors ont pris à mieux - peut - être qu'ils n'ont pas eu le coup de svnet gitest leur chance de fossé , il ^.

Les aînés se méfient des coûts d'opportunité - s'ils apprennent git, ils ne le sont pas:

  • Learning React / Angular / Swift / Blockchain / Kotlin (une autre chose qu’ils estiment devoir apprendre).
  • Faire du bricolage / du taillage / de la voile / de la poésie / du glockenspiel / tout ce qu’ils veulent réellement faire.
  • Passer du temps avec leurs enfants / parents / amis / proches.
  • Livrer cette "grande nouvelle chose" - il y a une échéance, 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 source?"

Quelles raisons leur avez-vous données pour passer d'une chose pour laquelle ils sont doués à une autre chose qui est franchement gênante lorsque vous débutez dans ce domaine et qui nécessite une refonte complète de la façon dont vous devenez développeur? Avez-vous expliqué les avantages des gitfonctionnalités?

Demandes de tirage? Checkins à grain fin? Source distribuée? Des fourchettes?

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

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 svnc'est stupide et vieux et que personne n'en utilise plus, alors c'est bien, mais c'est plus difficile à vendre à d'autres qui ne pensent pas comme vous et qui veulent juste passer à autre chose. Vous devez énoncer les avantages de manière cohérente pour votre équipe et pour le projet. Si vous pouvez les convaincre que cela en gitvaut la peine, vous n'avez pas à vous soucier de leur apprentissage de la technologie, mais simplement à accepter 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 quand il s'agit de problèmes techniques. Jeter juste cela comme une raison jusqu'à ce qu'il n'y ait aucune autre explication.

^ et être plus employable, ce qui est une chose à laquelle les aînés ne pensent peut-être pas autant, surtout compte tenu de l'âgeisme qui prévaut dans notre industrie.

Conradj
la source
3

Je pense qu'il s'agit moins d'une question d'ingénierie logicielle que d'une question de psychologie. Je voudrais faire référence à 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 existe une théorie mathématique solide qui explique pourquoi tel 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 demandait aux participants plus âgés s'ils souhaitaient rencontrer une personne célèbre qui leur plaît ou plutôt un membre de la famille. Ils choisissent généralement le membre de la famille, tandis que les plus jeunes choisissent 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 ont également choisi de manière routinière le personnage célèbre. Ce qui suggère que les gens arrêtent de construire leurs réseaux sociaux quand ils pensent avoir moins d'explorations que d'exploiter ce qu'ils savent déjà.

Vos ingénieurs principaux sont probablement plus âgés, ils ont probablement passé par quelques systèmes de contrôle de version. SVNest probablement le meilleur qu’ils aient utilisé jusqu’à présent (du moins en regardant les anciens systèmes de gestion de versions que j’avais utilisés, SVN les a tous battus).

Leur stratégie optimale consiste à exploiter SVN, car ils ont fait leur exploration et ont découvert que c’était le meilleur qu’ils exploitent maintenant.

C’est une psychologie humaine fondamentale, et des centaines de milliers d’années d’optimisation de l’évolution contre lesquelles vous vous battez.

Vous devrez leur montrer a) combien de temps ils ont devant eux, pour les inciter à penser sous un angle différent à l'intervalle sur lequel ils se voient et b) leur demander ce qu'ils pensent être génial et ce qu'ils ' re manque dans SVN. Vous pouvez présenter des centaines d'avantages git, mais ils auront déjà une idée claire de la raison pour laquelle ils SVNsont les meilleurs, après tout, ils ont probablement déjà utilisé 5 systèmes de contrôle de version. Vous devez trouver la faille dans l'armure de cet argument, et ensuite voir si vous gitpouvez résoudre ces problèmes, ils se seront alors convaincus.

CodeMonkey
la source
2

Ne leur donnez pas un outil ou une interface graphique pour utiliser Git. Cela ne fera que brouiller les choses. Git a été conçu pour être exécuté sur une ligne de commande, il devrait donc être le lieu où il est appris. Toute interface graphique peut venir avec ses propres termes et particularités, s'en tenir à ce qui est simple.

Nous examinerons ensuite certains problèmes que Git fait mieux que SVN. Pour que votre équipe l'apprenne, vous devez les motiver à comprendre pourquoi git est meilleur.

  • Possibilité de s’engager sans être connecté au réseau
  • Capacité à fabriquer et à jouer avec ses propres branches
  • Les patchs qui peuvent être envoyés entre eux et continuent de fusionner les pistes
  • 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 beaucoup de douleur. Si les développeurs constatent que ce nouvel outil n’est pas simplement une fantaisie, mais présente de solides avantages pour leur travail, ils seront probablement plus enclins à l’accepter.

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

Jeremy French
la source
1
+1 Autre que les sujets très avancés comme la cueillette de cerises et le rebasement (pour moi, la science de la fusée), apprendre avec la ligne de commande est un conseil qui a beaucoup de sens. C'est la seule façon d'apprendre réellement Git. Vous devez d'abord apprendre le HTML avant d'utiliser Dreamweaver, n'est-ce pas? Je créerais des alias pour les commandes les plus courantes avant de commencer. Par exemple, la commande Journal est byzantine et mystérieuse. Créez-leur un alias qui imprime une belle histoire.
Tulains Córdova
7
Je suis totalement en désaccord. Une vue du groupe de disponibilité de base est de loin l'outil le plus important pour comprendre ce qui se passe. Une vue qui ne viendra que d'une interface graphique.
Esben Skov Pedersen
1
git log --graph --abbrev-commit --decorate --date=relative --all
Jeremy French
1
git guiet gitkvenez avec le paquet principal git, et n'essayez pas de faire en sorte que git ressemble à autre chose. Ils sont excellents, en particulier gitk --allpour voir toutes les branches et pour remettre à zéro la branche actuelle afin de pointer vers d'autres commits ou des choses du genre. Dans gitk, "sélectionner" est l'une des options que vous obtenez lorsque vous cliquez avec le bouton droit de la souris sur un commit. Il utilise la même terminologie que les outils de ligne de commande.
Peter Cordes
3
@JeremyFrench L’art ASCII n’est pas un moyen très utile de visualiser un graphique aussi complexe qu’un repo git.
jpmc26
2

Dites-leur de ne pas s'inquiéter

Dans 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 ça git reflogmarche. Ils n'ont pas besoin de savoir comment l'utiliser. ils ont juste besoin de savoir que c'est là pour pouvoir obtenir de l'aide afin de récupérer leur travail en cas de problème.

Puis leur faire comprendre cette règle simple: en cas de doute, engagez-vous. Ils peuvent toujours annuler le commit plus tard (même à partir de la télécommande!).

Ne pas utiliser une interface graphique

Une interface graphique leur donnera un départ plus rapide, mais ils ne comprendront jamais vraiment Git. En outre, j’ai constaté qu’il n’était pas "presque impossible de perdre" un 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ésélectionne un élément, efface ce fichier de l'historique sans avertissement ni enregistrement. Une interface graphique est bien pire que le simple apprentissage de Git en ligne de commande.

Le code de programme en paire commet

L'apprentissage git add -Asuivi de git commitne devrait pas être trop difficile, mais surtout lors de la fusion (ou du rebasement) contre la télécommande, ils auront besoin d'aide. Indiquez clairement que toute personne est la bienvenue pour demander de l’aide à tout moment. Veillez pendant qu'ils tapent les commandes et prennent des notes. Avec le temps, ils augmenteront progressivement le nombre de situations qu’ils peuvent gérer sans aide.

Git est déjà en sécurité

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

  • Code non validé
  • Utiliser une interface graphique

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

Kyralessa
la source
1

Je conseillerais un coup d'oeil à Gitless . C'est un wrapper over git qui simplifie beaucoup le workflow de base (pas besoin de s'inquiéter d'une zone de stockage intermédiaire , les branches conservent leurs propres copies de travail des fichiers, les utilisations plus simples de git rebasesont gérées avec gl fuse, etc.) tout en conservant un référentiel git sous-jacent pour la collaboration. ou si vous avez besoin de faire quelque chose d'inhabituel. De plus, les messages sont un peu plus conviviaux pour les novices. Et les commandes sont suffisamment proches pour qu’ils agissent comme un tremplin s’ils doivent utiliser un système sans implacable pour quelque raison que ce soit.

David Heyman
la source
1
C'est une idée très intéressante, mais je dois me demander si, si Gitless n'est pas vraiment simple comme un mort (et qu'est-ce que c'est?), Alors investir dans son apprentissage pourrait être une perte de temps. Vous pourriez aussi bien faire un petit effort supplémentaire pour apprendre git, ce qui serait une compétence plus polyvalente et commercialisable. Peut-être si nous pourrions convaincre Torvalds, Hamano et al. pour intégrer l'interface Gitless, alors nous aurions vraiment quelque chose.
Cody Grey
Eh bien, c'est aussi simple que vous allez entrer dans le champ d'une porcelaine compatible avec Git. Toutes les commandes habituelles sont des opérations uniques avec des noms distincts et aucun argument n'est nécessaire.
David Heyman
0

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-même (qui avait déjà utilisé Perforce et Source Safe), et pour les programmeurs qui préféraient l'ancien paradigme «il suffit de compresser les dossiers pertinents». Il était inquiétant de voir un outil opaque modifier le contenu de mon répertoire de travail et devoir souvent discuter avec cet outil pour intégrer des modifications particulières 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 en 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, 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 beaucoup plus à l'aise que tout changement dans mon répertoire de travail correspond à ce que je souhaitais.

Jaspe
la source
0

Est-ce que je peux 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’ai compris de ce commentaire, c’est que la direction a décidé de changer quelque chose sans obtenir l’assentiment des principaux contributeurs et demande à une personne inférieure de diriger le changement. Cela semble être un bon point de départ pour l'échec, quel que soit le changement. La complexité des git n'est pas un problème, le problème est qu'un changement dont ils ne sentent pas le besoin leur est imposé.

Donc, ne vous concentrez pas sur la façon de leur apprendre le git, tant qu'ils ne voient pas l'avantage de l'interrupteur qu'ils traînent les pieds. Montrez-leur que 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, comment Git résout les problèmes qu’ils combattent actuellement. Ensuite, leur apprendre que Git ne sera pas un problème.

Programmateur
la source
0

Git est souvent utilisé dans une entreprise pour résoudre des problèmes de branches. Oui, c'est mieux sur les branches que sur Subversion, mais cela ne fait pas de magie.

Il est très probable que les développeurs expérimentés travaillent dans de nombreuses entreprises.

  • Les branches créées car la direction n'est pas disposée à choisir entre des demandes contradictoires
  • Avoir utilisé une branche pour chaque client plutôt que des commutateurs de configuration.
  • Avoir eu une branche de correction de bogue 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, il me le dit.

La direction ne veut pas décider de la direction que prend la société et préférerait que ma vie soit gâchée par la fusion de mon travail dans 101 branches différentes, ainsi que par le test de 101 versions différentes du logiciel.

De plus, le concept selon lequel deux personnes travaillant sur le même fichier simultanément est «bon», n’est tout simplement pas acceptable pour une personne qui a connu un projet bien géré. Il est donc peu probable que Git soit un outil pour le faire. les développeurs vous aiment.

Chaque fois que j'examine l'historique dans Git, il est très difficile de comprendre pourquoi le code a changé. En effet, 50% ou plus de l'historique sont des fusions qui, logiquement, n'auraient jamais dû être publiques, et elles perdent toute signification dès que le code quitte les développeurs. machine.

Mais j'aimerais travailler quelque part où:

  • Aucun code n'entre 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 critiques de code.
  • Où chaque fois que je fais un "get", le code est toujours compilé et fonctionne
  • Où je peux pousser mes changements sans avoir à faire la course avec quelqu'un d'autre, ou avoir à m'égarer au bureau pour voir si j'ai cassé la construction.

Résolvez donc les vrais problèmes et si Git fait partie des solutions que vos développeurs expérimentés accepteront, mais ne vous attendez pas à ce qu’ils apprécient Git simplement parce que c’est un jouet génial capable de faire de la “fusion magique”.

Par conséquent, tout endroit qui laisse un développeur pousser son Git local vers le Git central ne le fait pas correctement, un processus automatisé contrôlé devrait prendre les modifications des développeurs et après les avoir testées, etc., et vérifier que les fusions sont correctes pour mettre à jour le Git central et lui donner une apparence satisfaisante. branches etc. qui ne sont pas d'intérêt à long terme.

Je pense que Kiln ( http://www.fogcreek.com/fogbugz/devhub ) ou même que GitHub utilisant un flux de travail «demande d'extraction» satisferait les développeurs expérimentés, par exemple, ne commencez pas par le niveau bas pris, commencez par l'amélioration processus.

Ian
la source
1
Les raisons de la transition vers Git sont les suivantes: 1. Conseils et documentation de la communauté 2. Compatibilité avec les outils à grande échelle 3. Aucun verrou fournisseur. Nous avons construit un pipeline d’outils (principalement jira> bitbucket> bamboo) qui impose la révision du code et les tests unitaires avant la réintégration. Qu'est-ce qui vous a donné à penser que nous sommes des cow-boys?
Gusdor
@Gusdor parce que GIT a été créé pour des organisations sans contrôle central, par exemple des cow-boys .....
Ian
Du corps de la question: "Nous utilisons un modèle Git Flow centralisé ..."
Gusdor
1
C'est un point intéressant. Lorsque j'ai été embauché pour la première fois, le VCS a explosé et on m'a demandé mon avis sur le remplacement. J'ai choisi SVN parce que je pensais que GIT ne pourrait pas être utilisé de manière centralisée. Pas sûr que beaucoup de nos gars naviguent SO SO: O
Gusdor
1
@Ian Selon ce raisonnement, tous les utilisateurs d'Internet défendent les intérêts militaires américains, car le proto-Internet a été créé à l'origine par et pour l'armée (DARPA). De plus, toute personne portant des chaussures à sangle velcro est évidemment de la NASA, car le velcro a été inventé pour les applications zéro-g.
maple_shaft