Devrais-je m'attendre à ce que mon équipe ait plus qu'une connaissance de base de notre système de contrôle de source?


48

Ma société est passée de Subversion à Git il y a environ trois mois. Nous avons eu des semaines de préavis avant le changement. Comme je n’avais jamais utilisé Git (ni aucun autre DVCS), je lisais Pro Git et passais un peu de temps à créer mes propres référentiels et à jouer, afin de pouvoir continuer à travailler avec un minimum de douleur lorsque nous changerions . Maintenant, je suis le «gars Git» par défaut.

À quelques exceptions près, la plupart des membres de mon équipe n'ont toujours aucune idée du fonctionnement de Git. Par exemple, ils considèrent toujours les branches comme des copies complètes du code source et vont même jusqu'à cloner le référentiel dans plusieurs dossiers (un par branche). Ils considèrent généralement Git comme une boîte noire effrayante.

Compte tenu de la nature fondamentale du contrôle à la source dans notre travail quotidien (sans parler de la quantité ridicule de pouvoir que nous offre Git), je suis d’avis que tout développeur qui n’atteint pas un certain niveau de maîtrise de cette fonction est un handicap .

Devrais-je m'attendre à ce que mon équipe comprenne au moins comment Git fonctionne en interne et comment l'utiliser au-delà des opérations les plus élémentaires d'extraction / fusion / insertion? Ou suis-je en train de faire quelque chose avec rien?


30
La société a-t-elle proposé une formation sur Git?
Yannis

9
Tout dev qui n'est pas productif est un handicap. En supposant qu'ils soient productifs dans l'ensemble, savoir ou ne pas savoir que c'est génial est sans importance. En fin de compte, il ne s'agit que d'un autre outil.
MrFox

9
J'appellerais comprendre comment les branches de Git travaillent dans le cadre de la "maîtrise de base" ...
Shauna

16
Si vos coéquipiers n'arrivent pas à comprendre Git, vous avez de plus gros problèmes que le contrôle de source.
Jordan Bentley

4
@Caleb Ce n'était pas une vantardise. Loin de là.
Joshua Smith

Réponses:


49

Le professionnalisme imposerait naturellement aux développeurs de se familiariser avec les outils standard de leur équipe, même s'ils sont nouveaux et inconnus (ou même indésirables).

Cependant, quelques éléments de votre message me font réfléchir.

Nous avons eu des semaines de préavis avant le changement.

Semaines? Échanger le contrôle des sources est un gros problème. Il aurait fallu attendre plusieurs mois à l' avance pour que de tels changements se produisent.

À quelques exceptions près, la plupart des membres de mon équipe n'ont toujours aucune idée du fonctionnement de Git.

Ainsi, votre entreprise a opté pour un système de contrôle de source que peu de personnes, à supposer quiconque, comprennent à l’époque?

À moins qu'il y ait un autre contexte, il semble que tout le mouvement ait été mal pensé (le déménagement, pas le choix - je suis un grand fan de git).


3
Accordé. Ils sont passés à un système que pratiquement personne n'a compris. Il aurait été sage d'offrir une formation avant le changement. Cependant, j'étais à l'aise avec Git avec moins d'une semaine de pratique. Je ne me sens pas trop fort, alors je me demande s'il est approprié de s'attendre à ce que les autres s'entraînent aussi.
Joshua Smith

3
Quelqu'un a-t-il pris la peine de déterminer vos flux de travail et de les mapper sur les primitives offertes par le nouveau VCS? Il est assez facile de se tirer dans le pied avec des commandes qui ressemblent à celles auxquelles vous êtes habitué, et vous avez vraiment besoin de quelqu'un pour orchestrer quelque chose comme ça. Où est le type responsable de ce changement?
Lars Viklund

19
@JoshuaSmith Lorsque vous modifiez des normes ou des outils de développement, vous devez toujours opérer sur une transition de style "Aucun enfant laissé derrière". L’équipe ne peut se déplacer qu’à la vitesse de son membre le plus lent. Assurez-vous donc que les choses soient aussi claires et claires que possible au plus bas niveau possible avant la transition. Vous pouvez certes attribuer à autant de personnes un passif que vous le souhaitez, mais éliminer le «passif» est une tâche difficile et compliquée, en particulier pour un élément aussi trivial qu’un outil de contrôle de source.
maple_shaft

3
On dirait que vous avez "Dumped GIT", plutôt que de "Déployer un nouveau système de contrôle de révision" - GIT est un programme qui effectue le contrôle de source. Il est pas un système de contrôle de code source -Que nécessiterait des manuels d'utilisation, la formation, les programmes d'entretien, la gestion du cycle de vie , etc. S'il vous plaît dites - moi que vous avez une sauvegarde en place
mattnz

7
Apprendre comment fonctionne git est assez trivial. Cela ne prend certainement pas un mois pour apprendre à l'utiliser. A mon avis, un simple "Les gars, nous allons utiliser git dans quelques semaines. Prenez quelques heures pour apprendre à l'utiliser, de nombreuses ressources sont en ligne." Aurait été plus que suffisant.
Moox

34

Nous avons introduit Git là où je travaille et il y a naturellement eu de la résistance. Comme il s’agissait d’un nouveau projet, nous gérons maintenant deux référentiels.

Une partie du problème est que les utilisateurs ne verront pas les avantages de passer à un autre GDS lorsque celui qu'ils ont utilisé leur convient. Cela nous a aidé lorsque nous avons rencontré notre équipe pendant quelques séances d'une heure, où nous n'avions qu'à montrer les cas d'utilisation de nos projets et comment Git avait facilité la tâche. Par exemple, les choses qui nous ont aidés:

  • Les branches locales pour encourager l'expérimentation
  • Gect bisect pour traquer facilement les bugs
  • commets fréquemment sans interrompre les autres
  • Commutation rapide entre les branches

etc. Chacun de ces problèmes a résolu un problème que nous avions rencontré avec notre précédent SCM et ainsi les gens pouvaient apprécier Git davantage.

L'autre chose est que vous ne pouvez pas vous attendre à ce que les gens aillent lire des livres à ce sujet, car très peu le feront. Ils ont peut-être besoin de travailler, d'avoir d'autres responsabilités ou un certain nombre de raisons.

En tant qu’expert Git, vous devez donc vous asseoir et le rendre aussi simple que possible. Ils veulent écrire du code et ne pas jouer avec leur système SCM.

La CLI de Git est cryptique et des problèmes triviaux (pour vous et moi) empêcheront les gens de travailler. Voici ce qui s'est passé dans notre équipe (attention, ce sont des développeurs assez compétents):

  • Git avec SSH sous Windows était un problème courant.
  • Les gens tiraient, fusionnaient, mais ne poussaient pas la fusion. Donc, le graphique serait un énorme gâchis déroutant
  • Problème de performance sous Windows, le "statut git" prend 15 secondes
  • Impossible de comprendre comment créer une nouvelle branche. Ils feraient un "git checkout -b" qui dériverait de ce sur quoi ils travaillaient
  • EGit dans Eclipse avait un menu écrasant. J'ai fini par dire à tout le monde d'utiliser la ligne de commande au début
  • Basé sur l'élément précédent, fusion et configuration de git mergetool
  • Confus au sujet des différences entre "git add" et "git commit" et "git push".

Nous avons toujours une certaine résistance mais les gens peuvent certainement en voir les avantages. Il est essentiel de pouvoir compter sur quelques personnes Git pour les aider et être disposées à les aider. J'éviterais également d'enseigner des choses intéressantes comme réinitialiser / rebaser / modifier / etc. comme la plupart des gens utiliseront Git comme SVN, il est préférable de les laisser le découvrir s'ils le souhaitent.


7
@ JoshuaSmith Vous semblez avoir de grandes attentes envers les gens. Vous sentez-vous souvent déçu par vos pairs?
maple_shaft

4
@maple_shaft Je suis rarement déçu par mes pairs de cette équipe (mon dernier emploi était une histoire différente). Ici, les gens ici sont professionnels et travaillent avec plaisir. Et oui, j'ai de grandes attentes pour moi et pour ceux qui m'entourent. Je ne suis pas un imbécile à ce sujet cependant. C'est probablement naïf, mais j'estime que nous nous améliorerons inévitablement si nous demandons tous l'excellence.
Joshua Smith

9
@ JoshuaSmith, si vous vous attendez à ce que les gens aient régulièrement le temps de lire des livres, je vais vous poser une question: vous n'avez pas d'enfants, n'est-ce pas?
Kyralessa

13
@ JoshuaSmith les gens sont-ils payés pour lire ces livres? Si mon patron me disait "on change de technologie, je m'attends à ce que tu l'aies appris pendant ton temps libre le mois prochain", je serais assez énervé.
Matsemann

13
@ JoshuaSmith, oui, je dirais que oui - tout ce qu'un employé fait pendant son temps libre est extra, pas obligatoire. Vous devez donc leur fournir suffisamment d'informations pour utiliser l'outil ou suffisamment de temps au travail pour qu'ils puissent l'apprendre eux-mêmes (généralement sous forme de formation, même s'il ne s'agit que d'une session de formation à l'heure du déjeuner). Maintenant, si les employés étaient des pigistes, il y a de bonnes chances qu'ils se soient formés eux-mêmes, mais pas pendant leur contrat. Les employés s'attendent à certains avantages - tels que la formation, et à ne pas être stressés par un changement d'emploi, ce qui les prive de tout cela.
gbjbaanb

13

Proficient vs Git-mania

Un terme comme compétence de base peut signifier différentes choses pour différentes personnes. Beaucoup de gens semblent avoir une git-mania (pas qu'il y a quelque chose qui cloche avec ça). Beaucoup d'entre nous ont été gravement brûlés par le manque de contrôle de la source que nous avons mis en place avec ceux des autres.

Pourquoi c'est si important

Les outils de contrôle de la source sont essentiels car une mauvaise utilisation peut ralentir non pas une seule personne, mais toute une équipe. L'utilisation abusive de Git devrait être moins problématique que l'utilisation abusive de SVN, de CVS et d'autres systèmes. Historiquement, l’utilisation inepte de systèmes de verrouillage de fichiers était particulièrement problématique, et les entreprises embauchaient des équipes de construction distinctes. Ainsi, en cas de problème, un expert connaissant parfaitement le sujet ne maîtrisait presque jamais le contrôle de la source et pouvait guérir la plaie. Cela explique en partie une partie de la passion que vous trouvez derrière git.

À quoi ressemble la compétence de base?

Certains critères concrets incluent:

  • Sans référence à la documentation:

    • Peut ajouter des fichiers, valider des modifications, pousser et extraire des mises à jour.
    • Peut voir le statut et l'activité de révision.
    • Peut créer des branches et fusionner rapidement et sans introduire d’erreurs.
    • Peut utiliser la commande de manière appropriée.
    • Créez des commentaires de validation répondant aux critères de commentaires du groupe.
    • Diff change entre la copie de travail et l'archive.
  • Avec documentation:

    • Ajoutez des utilisateurs et des informations d'identification pour le référentiel local.
    • init un repo local.
    • Administrer le dépôt à distance.
    • Configurez les fichiers ignorés, générez des paires de clés publique / privée PKI.
    • Déplacer et supprimer des fichiers.
    • Utilisez bissecter pour trouver le changement qui a introduit un bogue particulier.

Un modèle mental solide de git et du code géré est essentiel pour éviter les erreurs.

Qu'ajouteriez-vous pour une compétence / expertise avancée?

L'utilisation courante est essentielle pour les développeurs et éventuellement pour d'autres membres de votre équipe. Des outils tels que Git sont des frais généraux et doivent être appris à un niveau où ils peuvent être presque automatiques. La réduction du temps et des distractions générés par l’utilisation de commandes git répétées des milliers de fois par an a une grande valeur.

Il y aura toujours des membres de votre équipe qui seront des utilisateurs expérimentés et utiliseront presque toutes les commandes avec presque toutes les options. Ma recommandation est que les membres de l'équipe soient encouragés à continuer à apprendre git (et autres outils) jusqu'à ce que le retour sur investissement de l'apprentissage devienne inférieur à la valeur de faire autre chose sur le projet, la principale limitation étant de rester en phase avec les éléments de burn-up assignés de l'actuel sprint.


11

GIT est un outil juste pour faire un travail, et l'un de ses plus gros problèmes est que de nombreux évangélistes du GIT attendent de tous les utilisateurs de GIT qu'ils deviennent des experts du bonnet qui comprennent les points les plus précis de son fonctionnement. C'est la plus grande faiblesse de GIT - pour l'utiliser, vous devez savoir comment cela fonctionne. Il n'y a pas de recettes avec GIT, vous êtes censé être un expert GIT ou ne pas l'utiliser. C'est bien que vous lisiez Pro-GIT, votre organisation a besoin d'un gourou "goto" GIT (ou deux) pour maximiser ses investissements, car tous les développeurs ne veulent pas devenir un gourou GIT - et ce n'est pas grave.

L’équipe doit savoir comment utiliser GIT (en fait, elle doit seulement savoir comment utiliser les parties de GIT que le flux de travail les oblige à utiliser), et non pas comment GIT fonctionne. Il est préjudiciable d'attendre de chaque développeur qu'il connaisse chaque détail de chaque outil qu'il utilise. Si vous ne disposez pas d'un livre de recettes prenant en charge votre flux de travail, vous n'avez pas déployé GIT, vous l'avez transféré aux développeurs.

Je ne donne pas à un singe comment fonctionne GIT, tant que je sais comment faire fonctionner git pour moi.


1
Et il existe un besoin de formation personnalisée ... et encore une fois, ni Linus ne s'attend à ce que quiconque embrasse toutes les techniques de Git, c'est pourquoi il existe deux classes de commandes: la porcelaine et la plomberie.
ZJR

1
Il existe de nombreuses recettes pour git si tout ce que vous voulez faire est de migrer d'un flux de travail utilisé dans Brand X vers un flux de travail dans Git.
Jherico

10

Oui.

Quel que soit l'outil choisi par "l'entreprise", votre équipe de développement devrait passer un certain temps à apprendre à utiliser correctement l'outil. Rien ne nuit plus à la productivité qu'un groupe de développeurs effrayés ou ignorants d'un outil. S'ils l'utilisent mal ou s'y opposent, des problèmes se poseront et, en tant que type, vous serez chargé de nettoyer le désordre.

Git est une transition difficile pour beaucoup, donc une séance d'entraînement assis obligatoire peut être appropriée. Cela devrait aider à résoudre bon nombre des problèmes que rencontrent les gens.


3
"Rien ne nuit plus à la productivité qu'un groupe de développeurs effrayés ou ignorants d'un outil." On peut donc supposer qu’une entreprise serait folle de vivre avec un outil dans lequel l’équipe n’a pas été formée et ne comprend pas.
Jaydee

Les entreprises, surtout les grandes, doivent parfois recourir à la technologie. Il peut également s'agir d'une équipe au sein d'une organisation qui a déjà effectué la poussée initiale et utilise pleinement l'outil.
Bill Leeper

3

Je n'ai utilisé Git que dans un cadre personnel et non professionnel. Bien que j'aime son pouvoir et l'idée d'un contrôle à la source plus décentralisé, il pose de gros problèmes. Git a une abstraction qui fuit et il faut plusieurs commandes pour faire des choses simples (par exemple pour faire un changement: git add, git commit, puis git push). De plus, une partie de la documentation manque et / ou est source de confusion, comme dans la description de la commande rebase ... "Le port local de port de transfert est validé dans l'en-tête amont mis à jour". Je n'ai aucune idée de ce que cela signifie, et bien que je sache maintenant que vous pouvez vous déplacer et réécrire l'histoire avec elle (un autre ennui ... pourquoi devriez-vous être autorisé à le faire ???), je n'aurais jamais deviné que cette commande la description. Je pense que la lecture de votre équipe et une formation supplémentaire que vous avez fournie sont en ordre.


2

La formation et la compréhension sont les exigences minimales. Quelqu'un en charge aurait dû s'assurer qu'il y avait un plan sur la façon dont votre équipe l'utiliserait. Vous n'adopteriez pas un nouveau langage de programmation sans directives. La formation des conducteurs est beaucoup plus efficace lorsque les règles de la route établies sont incorporées.


1

Non; Je pense qu'il est raisonnable de s'attendre à ce qui suit:

  1. Effectuer des tâches quotidiennes (commettre, pousser, tirer, ramifier, fusionner, bissecter, etc.) sans tenir par la main.
  2. Effectuer des tâches non routinières sans instruction répétée. (Quelques répétitions sont acceptables - je dois rencontrer quelqu'un 2 à 3 fois avant que son nom ne colle vraiment.)

S'ils ne peuvent pas faire # 1, alors la partie formation de votre déploiement était probablement insuffisante. S'ils ne peuvent pas faire le n ° 2, assurez-vous d'abord que vous expliquez les choses suffisamment clairement avant de vous énerver.


Ce n'est pas vraiment une réponse à la question; la question était de savoir quel niveau de compétence devrait-il attendre des autres, et non comment il améliorerait leurs compétences. J'éliminerai le vote négatif lorsque vous m'annoncez en commentaire avec @MyName que vous avez corrigé votre réponse pour qu'elle soit dans le sujet.
Jimmy Hoffa

@ JimmyHoffa Je pense que vous avez mal compris ma réponse. Ils doivent maîtriser leurs tâches quotidiennes et de routine, et assumer les autres tâches assez rapidement. J'ai identifié quelques causes possibles , mais j'ai essayé d'éviter de prescrire des mesures correctives. Vous lisez entre les lignes et extrapolez si c'est ce que vous voyez.
pgs

Non, la question est "Devrais-je m'attendre à ce que mon équipe ait plus qu'une compétence de base ..." et vous n'avez pas dit "Oui, voici pourquoi" ni vous avez dit "Non, voici pourquoi". Vous avez répondu à une question par une question. J'apprécie le fait que votre réponse soit réfléchie et que le contenu soit utile, mais vous devez tout de même répondre à la question par un oui ou un non et essayez de justifier pourquoi vous pensez un oui ou un non ... Alors n'hésitez pas à laisser votre réponse sous le contenu actuel . Avoir un sens?
Jimmy Hoffa

@ JimmyHoffa Ma réponse est "Non, voici un minimum auquel vous devriez raisonnablement vous attendre"; Je ne l'ai tout simplement pas dit avec ces mots exacts.
pgs

Oh, je pensais que vous faisiez allusion à un "oui", mettez cette préface dans le document et cela répond à la question, sinon cela n'a aucun sens heh
Jimmy Hoffa
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.