Dovrei aspettarmi che il mio team abbia più di una competenza di base con il nostro sistema di controllo del codice sorgente?

La mia azienda è passata da Subversion a Git circa tre mesi fa. Abbiamo avuto settimane di preavviso prima del passaggio. Dal momento che non avevo mai usato Git prima (o qualsiasi altro DVCS), ho letto Pro Git e ho trascorso un po 'di tempo a girare i miei repository e a giocare, in modo che quando saremmo passati sarei stato in grado di continuare a lavorare con il minimo dolore. Ora sono il 'Git guy' di default.

Con un paio di eccezioni, la maggior parte del mio team non ha ancora idea di come funzioni Git. Ad esempio, pensano ancora ai rami come copie complete del codice sorgente e arrivano persino a clonare il repository in più cartelle (una per ramo). In genere guardano a Git come una scatola nera spaventosa.

Data la natura fondamentale del controllo delle fonti nel nostro lavoro quotidiano (per non parlare della ridicola quantità di potere che Git ci offre), sono dell'opinione che qualsiasi sviluppatore che non raggiunge un certo livello di competenza con esso sia una responsabilità .

Dovrei aspettarmi che il mio team abbia almeno una certa comprensione di come Git lavora internamente e di come usarlo oltre le più semplici operazioni pull / merge / push? O sto solo facendo qualcosa dal nulla?

La professionalità imporrebbe naturalmente che uno sviluppatore acquisisca familiarità 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.

Abbiamo avuto settimane di preavviso prima del passaggio.

Settimane? Scambiare il controllo del codice sorgente è un grosso problema. Ci dovrebbero essere stati mesi di preavviso che hanno portato a un cambiamento del genere.

Con un paio di eccezioni, la maggior parte del mio team non ha ancora idea di come funzioni Git.

Quindi, la tua azienda è passata a un sistema di controllo del codice sorgente che pochi, se nessuno, hanno capito al momento?

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

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

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

• Filiali locali per incoraggiare la sperimentazione
• Git bisect per rintracciare facilmente i bug
• si impegna frequentemente senza interrompere gli altri
• Cambio rapido tra i rami

ecc. Ognuno di questi ha risolto un problema che avevamo riscontrato con il nostro precedente SCM e quindi le persone potevano apprezzare di più Git.

L'altra cosa è che non puoi aspettarti che le persone se ne vadano a leggere libri perché pochissimi lo faranno. Forse hanno bisogno di lavorare, avere altre responsabilità o qualsiasi numero di ragioni.

Quindi, come "esperto Git" devi sederti e rendere il più semplice possibile l'utilizzo da parte delle persone. Vogliono scrivere codice, non scherzare con il loro sistema SCM.

L'interfaccia della riga di comando di Git è criptica e problemi insignificanti (per me e te) impediranno alle persone di lavorare. Ecco cosa è successo al nostro team (attenzione, questi sono sviluppatori abbastanza competenti):

• Git con SSH su Windows era un problema comune.
• Le persone tirerebbero, si fonderebbero, ma non spingerebbero l'unione. Quindi il grafico sarebbe un enorme casino confuso
• Problema di prestazioni su Windows fatto "stato git" richiede 15 secondi
• Impossibile capire come tirare un nuovo ramo. Avrebbero fatto un "git checkout -b" che si sarebbe ramificato da qualunque cosa stessero lavorando
• EGit in eclipse aveva un menu travolgente. Finì per dire a tutti di usare inizialmente la riga di comando
• Basato sull'elemento precedente, unione e configurazione di git mergetool
• Confuso sulle differenze tra "git add" e "git commit" e "git push".

Otteniamo ancora qualche resistenza ma le persone possono sicuramente vedere i benefici. È fondamentale avere alcune persone Git come guida ed essere disposti ad aiutare. Inoltre, eviterei di insegnare cose interessanti come reset / rebase / - edit / etc. poiché la maggior parte delle persone utilizzerà Git come SVN, è meglio lasciarlo 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 gravemente bruciati dalla sciatta propria e altrui con il controllo delle fonti.

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'uso improprio di SVN, CVS e altri sistemi. Storicamente, l'uso inetto di sistemi che bloccavano i file era particolarmente problematico e le aziende assumevano team di costruzione discreti in modo che quando qualcuno si metteva nei guai, c'era un esperto fluente che non faceva quasi altro che il controllo del codice sorgente che poteva curare la ferita nel repository. Questo spiega in parte parte della passione che trovi dietro Git.

Che aspetto ha la competenza di base?

Alcuni criteri concreti includono:

• Senza riferimento alla documentazione:

  • Può aggiungere file, eseguire il commit delle modifiche, push e pull aggiornamenti.
  • Può visualizzare lo stato e l'attività di revisione.
  • Può ramificarsi e fondersi rapidamente e senza introdurre errori.
  • Può utilizzare il checkout in modo appropriato.
  • Crea commenti di commit che soddisfino i criteri del gruppo per i commenti.
  • Il diff cambia tra copia di lavoro e archivio.

• Con documentazione:

  • Aggiungi utenti e credenziali per il repository locale.
  • avviare un repository locale.
  • Amministrare repository remoto.
  • Configurare i file ignorati, generare coppie di chiavi pubbliche / private PKI.
  • Sposta ed elimina i file.
  • Usa bisect per trovare la modifica che ha introdotto un particolare bug.

Un solido modello mentale di git e il codice gestito sono fondamentali per evitare errori.

Cosa aggiungeresti per competenza / competenza avanzata?

L'uso fluido è essenziale per gli sviluppatori e, eventualmente, per alcuni altri membri del tuo team. Strumenti come Git sono generali e dovrebbero essere appresi a un livello in cui possono essere quasi automatici. Ridurre al minimo il tempo e la distrazione prodotti utilizzando i comandi git che vengono ripetuti migliaia di volte all'anno ha un valore elevato.

Ci saranno sempre alcuni membri del tuo team che saranno utenti esperti e useranno quasi tutti i comandi con quasi tutte le opzioni. La mia raccomandazione è che i membri del team siano incoraggiati a mantenere l'apprendimento del git (e altri strumenti) fino a quando il ROI per l'apprendimento non scende al di sotto del valore di fare qualcos'altro sul progetto, con il limite principale essere al passo con gli oggetti di burndown assegnati dall'attuale sprint.

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

Il team deve sapere come utilizzare GIT (in realtà devono solo sapere come utilizzare le parti di GIT che il flusso di lavoro richiede loro di utilizzare), non come GIT funziona. È dannoso aspettarsi che tutti gli sviluppatori conoscano ogni dettaglio di ogni strumento che usano. Se non hai un ricettario che supporta il tuo flusso di lavoro, non hai distribuito GIT, lo hai scaricato sugli sviluppatori.

Non do una scimmia a come funziona GIT, purché sappia come farlo funzionare per me.

Sì.

Indipendentemente dallo strumento scelto dall'azienda, il team di sviluppo dovrebbe dedicare un po 'di tempo a imparare come utilizzare correttamente lo strumento. Nulla danneggia la produttività più di un gruppo di sviluppatori che hanno paura o ignorano uno strumento. Se lo stanno usando in modo sbagliato o lavorando contro di esso, sorgeranno problemi e, come per il ragazzo, ti verrà assegnato il compito di ripulire il pasticcio.

Git è una transizione difficile per molti, quindi una sessione di allenamento obbligatoria può essere in ordine. Questo dovrebbe aiutare a risolvere molti dei problemi che le persone stanno riscontrando.

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 della fonte più decentralizzato, ha grossi problemi. Git ha un'astrazione che perde 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 rebase ... "Il server forward-port si impegna sull'upstream head aggiornato". Non ho idea di cosa significhi, e anche se ora so che puoi spostare i commit e riscrivere la storia con esso (un altro fastidio ... perché dovresti essere autorizzato a farlo ???) Non avrei mai immaginato che da quel comando descrizione. Penso che un po 'di lettura da parte della tua squadra, e un po' più di allenamento fornito da te sia in ordine.

La formazione e la comprensione sono i requisiti minimi. Qualcuno in carica avrebbe dovuto assicurarsi che ci fosse un piano su come la tua squadra lo avrebbe usato. Non adotteresti un nuovo linguaggio di programmazione senza linee guida. L'addestramento del guidatore è molto più efficace quando sono incorporate le regole stradali stabilite.

No; Penso che sia ragionevole aspettarsi quanto segue:

1. Esegui attività quotidiane (commit, push, pull, branch, merge, bisect, ecc.) Senza tenere la mano.
2. Eseguire attività non di routine senza ripetute istruzioni. (Alcune ripetizioni sono ok - Devo incontrare qualcuno 2-3 volte prima che il loro nome rimanga davvero.)

Se non riescono a fare il n. 1, probabilmente la parte di allenamento del tuo lancio è stata insufficiente. Se non riescono a fare il secondo, assicurati di spiegare le cose in modo abbastanza chiaro prima di arrabbiarti troppo.