Cette réponse tente de déterminer comment intéresser les programmeurs expérimentés git
, et non comment apprendre git
le 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 git
geek et je voulais transformer une équipe svn
avec 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 git
vous avez toujours pour effet spécifique "Pourquoi devrions-nous l'utiliser du tout si svn
tout va bien?", Ce qui constitue un obstacle psychologique énorme.
De plus, le fait de rigoler git
né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 add
dans 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 gitk
en dernier recours. Si vos gars utilisent n’importe quel type d’éditeur visuel, trouvez leur git
composant 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-file
pour 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
git
sous-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
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 sénateurs se souviendront peut-être que leurs composants internes svn
sont 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 svn
gars est qu’il svn
utilise 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 git
référentiel est composé, il est temps de leur montrer exactement ce que font les git
sous-commandes individuelles .
Je parle de add
, commit
en 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 push
et git pull
(en mode avance rapide!). ) pour leur montrer que, git
litté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.txt
ici.
Branches
Notez que la création de branches est particulièrement difficile pour les svn
utilisateurs, car elle est totalement différente. Le svn
modèle est beaucoup plus facile à visualiser car il n’ya fondamentalement rien à visualiser - il est bien visible. Le git
modè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 pull
c'est vraiment git fetch && git merge
; comment tous les référentiels contiennent exactement les mêmes objets ( git fetch
c'est presque la même chose que copier du contenu scp
dans 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 git
commandes par des scripts élaborés ou une interface graphique qui git
supprime tous les détails. Versez tout le contrôle d'erreur, etc. dans les scripts, et essayez de le faire fonctionner.