Devo aspettarmi che la mia squadra abbia più di una competenza di base con il nostro sistema di controllo del codice sorgente?

La professionalità imporrebbe naturalmente allo sviluppatore di familiarizzare con gli strumenti standard del proprio team, anche se sono nuovi e non familiari (o addirittura indesiderati).

Tuttavia, alcune cose nel tuo post mi danno una pausa.

We had weeks of advance notice prior to the switch.

Settimane? Scambiare il controllo del codice sorgente è un grosso problema. Dovrebbero esserci stati mesi di avviso che hanno portato a una modifica del genere.

With a couple of exceptions, most of my team still has no idea how Git works.

Quindi, la tua azienda è passata a un sistema di controllo del codice sorgente che pochi, se nessuno, ha capito all'epoca?

A meno che non ci sia un altro contesto, sembra che l'intera mossa sia stata mal concepita (la mossa, non la scelta - sono un grande fan del git).

Abbiamo introdotto Git dove lavoro e c'è stata naturalmente resistenza. Era per un nuovo progetto, quindi stiamo mantenendo due repository.

Una parte del problema è che le persone non vedranno i vantaggi di passare a un altro SCM quando quello che stanno usando funziona per loro. Ci ha aiutato quando ci siamo incontrati con il nostro team per un paio di sessioni di un'ora in cui mostriamo solo casi d'uso dei nostri progetti e in che modo Git ha reso tutto più semplice. Ad esempio, le cose che ci hanno aiutato:

• Filiali locali per incoraggiare la sperimentazione
• Git bisect per rintracciare facilmente i bug
• frequenti commit senza interrompere altri
• Passaggio veloce tra i rami

ecc. Ognuno di questi ha risolto un problema che avevamo riscontrato con il nostro precedente SCM e quindi la gente avrebbe potuto apprezzare di più Git.

L'altra cosa è che non puoi aspettarti che le persone se ne vadano a leggere libri su di loro perché pochissimi lo faranno. Forse hanno bisogno di portare a termine il lavoro, hanno altre responsabilità o un numero qualsiasi di ragioni.

Quindi, come esperto di Git, devi sederti e renderlo il più semplice possibile per le persone. Vogliono scrivere codice, non scherzare con il loro sistema SCM.

Le CLI di Git sono problemi criptici e banali (a te e io) impediremo alle persone di lavorare. Ecco cosa è successo nel nostro team (attenzione, questi sono sviluppatori abbastanza competenti):

• Git con SSH su Windows era un problema comune.
• Le persone attirerebbero, uniranno, ma non spingeranno all'unione. Quindi il grafico sarebbe un enorme pasticcio confuso
• Problemi di prestazioni su Windows creati con "stato git" occorrono 15 secondi
• Impossibile capire come estrarre un nuovo ramo. Farebbero un "git checkout -b" che si diramerebbe da quello su cui stavano lavorando
• EGit in eclissi ha avuto un menu travolgente. Finito per dire a tutti di usare la riga di comando all'inizio
• In base all'elemento precedente, fusione e impostazione di git mergetool
• Confuso riguardo alle differenze tra "git add" e "git commit" e "git push".

Abbiamo ancora qualche resistenza, ma le persone possono sicuramente vedere i benefici. È fondamentale avere alcune persone Git come guida e essere disponibili ad aiutare. Eviterei anche di insegnare cose interessanti come reset / rebase / - modify / etc. poiché molte persone useranno Git come SVN, è meglio lasciarle scoprire se lo desiderano.

Competente contro Git-mania

Un termine come competenza di base può significare cose diverse per persone diverse. Molte persone sembrano avere git-mania (non che ci sia qualcosa di sbagliato in questo). Molti di noi sono stati bruciati davvero male dalla nostra stessa e dalle altre persone con il controllo del codice sorgente.

Perché è importante (così tanto)

Gli strumenti di controllo del codice sorgente sono fondamentali perché l'uso improprio può rallentare non solo una persona, ma un'intera squadra. L'uso improprio di Git dovrebbe essere meno problematico rispetto all'utilizzo improprio di SVN, CVS e altri sistemi. Storicamente, l'uso inetto dei sistemi che bloccavano i file era particolarmente problematico, e le aziende assumevano team di compilazione discreti in modo che quando qualcuno si metteva nei guai, c'era un esperto fluente che non faceva quasi nulla che non potesse controllare la ferita al deposito. Questo spiega in parte parte della passione che trovi dietro git.

Che aspetto ha l'abilità di base?

Alcuni criteri concreti includono:

• Senza riferimenti alla documentazione:

  • Può aggiungere file, commutare modifiche, spingere e tirare gli aggiornamenti.
  • Può visualizzare lo stato e l'attività di revisione.
  • Può diramare e unire rapidamente e senza introdurre errori.
  • Può utilizzare la verifica in modo appropriato.
  • Crea commenti di commit che soddisfano i criteri del gruppo per i commenti.
  • Differenze tra copia e archivio di lavoro.

• Con documentazione:

  • Aggiungi utenti e credenziali per il repository locale.
  • avvia un repository locale.
  • Gestisci il repository remoto.
  • Configura i file ignorati, genera coppie di chiavi pubbliche / private PKI.
  • Sposta ed elimina file.
  • Utilizza la bisettrice per trovare la modifica che ha introdotto un particolare bug.

Un solido modello mentale di git e il codice che viene gestito è fondamentale per evitare errori.

Cosa aggiungeresti per competenza / esperienza avanzata?

L'uso fluido è essenziale per gli sviluppatori e forse anche per altri membri del tuo team. Strumenti come Git sono generali e dovrebbero essere appresi a un livello tale da poter essere quasi automatici. Ridurre al minimo il tempo e la distrazione generati dall'uso di comandi git che vengono ripetuti migliaia di volte all'anno ha un valore elevato.

Ci saranno sempre membri del tuo team che saranno utenti esperti e utilizzano quasi ogni comando con quasi tutte le opzioni. La mia raccomandazione è che i membri del team siano incoraggiati a continuare a imparare git (e altri strumenti) fino a quando il ROI per l'apprendimento scende al di sotto del valore di fare qualcos'altro sul progetto, con la limitazione principale mantenuta al passo con gli item burn-down assegnati dall'attuale sprint.

GIT è uno strumento giusto per fare un lavoro, e uno dei maggiori problemi è che molti evangelisti del GIT si aspettano che tutti gli utenti GIT diventino esperti del cofano che comprendono i punti migliori di come funziona. Questa è la più grande debolezza di GIT: per utilizzarla devi sapere come funziona. Non ci sono ricette con GIT, ci si aspetta che tu sia un esperto GIT o non lo usi. È fantastico che tu abbia letto Pro-GIT. La tua organizzazione ha bisogno di un guru GIT "goto" (o due) per massimizzare l'investimento in esso, perché non tutti gli sviluppatori vogliono diventare GIT Guru - e questo è OK.

Il team deve sapere come usare GIT (in realtà hanno solo bisogno di sapere come usare le parti di GIT che il flusso di lavoro richiede loro di usare), non come funziona il GIT. È dannoso aspettarsi che ogni sviluppatore sappia ogni dettaglio su ogni strumento che usa. Se non hai un ricettario che supporti il tuo flusso di lavoro, non hai implementato GIT, lo hai scaricato sugli sviluppatori.

Non concedo alle scimmie come funziona il GIT, a patto che sappia come far funzionare Git per me.

Sì.

Indipendentemente dallo strumento che la "compagnia" ha deciso, il tuo team di sviluppo dovrebbe dedicare del tempo a imparare come utilizzare correttamente lo strumento. Nulla danneggia la produttività più di un gruppo di sviluppatori che temono o ignorano uno strumento. Se stanno usando male o stanno lavorando contro di esso, sorgono dei problemi e, quando si va al ragazzo, ti verrà dato il compito di ripulire il casino.

Git è una transizione difficile per molti, quindi una seduta di allenamento sit down obbligatoria potrebbe essere in ordine. Questo dovrebbe aiutare a risolvere molti dei problemi che le persone stanno avendo.

Ho usato Git solo in un ambiente personale e non professionale, e mentre mi piace il potere che ha e l'idea di un controllo del codice sorgente più decentralizzato, ha grossi problemi. Git ha una strana astrazione e ci vogliono più comandi per fare cose semplici (ad esempio per fare una modifica: git add, git commit, quindi git push). Inoltre, parte della documentazione è carente e / o confusa come con la descrizione del comando di rebase ... "Il forward-port local si impegna sul capo upstream aggiornato". Non ho idea di cosa significhi, e anche se ora so che è possibile spostare i commit e riscrivere la cronologia (un altro fastidio ... perché dovresti essere autorizzato a farlo ???) non avrei mai immaginato che da quel comando descrizione. Penso che alcune letture da parte della tua squadra, e un po 'più di formazione fornita da voi è in ordine.

Formazione e comprensione sono i requisiti minimi. Qualcuno responsabile avrebbe dovuto assicurarsi che ci fosse un piano su come la tua squadra avrebbe usato. Non si adotterebbe un nuovo linguaggio di programmazione senza linee guida. L'addestramento del guidatore è molto più efficace quando vengono incorporate le regole della strada stabilite.

No; Penso che sia ragionevole aspettarsi quanto segue:

1. Esegui attività quotidiane (commit, push, pull, branch, unire, bisecare, ecc.) senza tenere in mano.
2. Esegui attività non di routine senza istruzioni ripetute. (Alcune ripetizioni vanno bene - Devo incontrare qualcuno 2-3 volte prima che il loro nome si attacchi davvero.)

Se non possono fare # 1, la parte di allenamento del tuo roll-out probabilmente non è stata sufficiente. Se non possono fare il n. 2, prima assicurati di spiegare le cose abbastanza chiaramente prima di arrabbiarti troppo.