Contesto

Il mio team di 8 ingegneri sta attualmente passando a Git (da Subversion) per la nostra prossima grande novità. Abbiamo una manciata di ingegneri "più esperti" che hanno difficoltà a raccogliere Git. Mi vengono poste le stesse domande banali nonostante abbia fornito manuali utente, attività di formazione e sessioni di lavagna. Avevamo due consulenti Junior che hanno raccolto tutto in pochi giorni e questo ha davvero chiarito la questione. Questo non è uno schema limitato a Git ma è diventato di conseguenza visibile.

Domanda

Non mi sento particolarmente favorevole agli ingegneri che non possono / non vogliono imparare - specialmente il personale con i livelli di anzianità che abbiamo qui. Tuttavia, voglio che il team abbia successo e costruisca un ottimo prodotto. Stiamo utilizzando un modello Git Flow centralizzato e credo che tutta la nuova terminologia li stia sconcertando.

C'è qualcosa che posso fare per aiutare questi dipendenti ad imparare Git?

Sourcetree è il client utilizzato da tutto il team.

Dai loro un giocattolo.

Git è difficile. Soprattutto se hai fatto il controllo del codice sorgente in un diverso paradigma. Ho rotto la build la prima volta che ho provato a lavorare con Git. Mi ha reso così paranoico che non volevo fare il check-in fino a quando non fosse stato fatto tutto. Nascondevo le versioni nelle cartelle. Poi ho finalmente capito cosa avevo bisogno per superarlo:

Avevo bisogno di un posto sicuro dove giocare.

Una volta che l'ho avuto, stavo causando intenzionalmente problemi in modo da poter imparare a risolverli, tutto nel mio posto sicuro. Ho sviluppato un modello che potrei usare anche se interrotto e comunque tornare in buono stato. In poco tempo, la gente veniva da me per chiedere aiuto con Git. Tutto perché mi sono preso il tempo di giocare con un giocattolo.

Se li lanci nel profondo, sarai fortunato se riusciranno a galleggiare.

Lo sviluppatore medio non ha bisogno di molte chicche di Git. È un sistema di controllo del codice sorgente distribuito ma la maggior parte dei team lo utilizzerà con un repository canonico centrale da cui spingere e tirare.

I comandi principali di cui il tuo team avrà bisogno sono:

• estrarre e unire le modifiche da remoto e gestire i conflitti risultanti (potenzialmente rebasing)
• commit e push commit in remoto (o push in repo / branch di gestione temporanea per ottenere le modifiche portate in main dopo la revisione)
• Per il supporto: correggi il disordine dopo aver fatto qualcosa di sbagliato.

quelli di cui avranno bisogno gli utenti più avanzati

• gestire gli commit locali
• gestire le filiali

Per le persone che non hanno familiarità con Git e per coloro che non vogliono apprenderlo, impostare alcuni comandi con alias rapidi per eseguirli e assicurarsi che tutto sia corretto (aggiungere nuovi file, rimuovere i file eliminati dal repository, ecc.)

Assicurati che siano ben documentati e decentemente a prova di errore.

Questo è nella vena del fumetto di xkcd , basta memorizzare i comandi e sperare che le cose non si incasinino troppo, quando lo chiedono a un professionista.

Fagli usare un'interfaccia utente di Git.

Se hanno esperienza con TortoiseSVN, TortoiseGit (solo Windows) funziona quasi esattamente allo stesso modo. Altrimenti, SourceTree (Windows + Mac) è meraviglioso: abbiamo più QA non per sviluppatori che sono stati in grado di gestire facilmente attività complesse in Git grazie a SourceTree.

Questa risposta cerca di indirizzare come interessare i programmatori senior git, non su come imparare gitnel modo più rapido - per questo, l'eccellente git book è eccezionale, o qualsiasi numero di tutorial (=> Google). Buoni collegamenti con questa risposta sono Git è una struttura di dati puramente funzionale o in particolare il breve How git archivia i tuoi dati .

Temo di avere una visione piuttosto desolante su questo. Sono stato esattamente nei tuoi panni: sono un gitsecchione e volevo trasformare una squadra lontano da svn, diciamocelo, risultati minuscoli. Nel mio caso mi ha portato a cambiare attivamente la mia percezione e ad accettare quella gente, semplicemente non può essere "costretto alla felicità". Le persone non sono computer, è incredibile programmarle. Sono ancora felice di aver provato, mi ha mostrato in modo piuttosto morbido cosa faccio e cosa non voglio fare nella mia vita professionale.

Ci sono persone che iniziano a motivarsi quando sono coinvolte nuove cose e ci sono persone demotivate. Questo non ha nulla a che fare con git, ma in gitparticolare si ha sempre l'effetto di "perché dovremmo usarlo se svnva bene?", Che è una massiccia barriera psicologica.

Inoltre, davvero il trekking gitrichiede un intenso interesse per le strutture di dati astratte. Può sembrare incredibile, ma nella mia esperienza ci sono programmatori che non hanno alcun interesse e che sono annoiati e sovraccaricati da elementi più complessi delle matrici semplici. Puoi discutere avanti e indietro se quelli dovrebbero fare il lavoro che stanno facendo, ma è quello che è.

Se le persone non sono interessate ad esso, non lo capiranno. Chiaro e semplice. Scommetterei che il disinteresse è la ragione principale dei cattivi voti a scuola, non della mancanza di intelligenza.

Detto questo, qui sarebbe un curriculum come lo applicherei, basato sull'accumulo di conoscenza dal basso verso l'alto. Non ha funzionato per me, ma potresti prenderlo come ispirazione per creare il tuo.

GUI

Sebbene il seguente approccio non necessiti necessariamente del supporto della GUI per le azioni ( git addin un repository ciao mondo ...), aiuta enormemente avere una GUI per visualizzare il repository, fin dall'inizio. Se non riesci a decidere su quale utilizzare, prendi gitkl'ultima risorsa. Se i tuoi ragazzi usano qualsiasi tipo di editor visivo, trova il loro gitcomponente GUI.

La struttura dei dati (statica) è la chiave

Inizia spiegando i tipi di dati interni (ce ne sono solo tre più uno: BLOB, alberi, commit, tag annotati, l'ultimo dei quali non interessa affatto in questa fase) e la loro struttura. Puoi farlo facilmente sulla lavagna / con una matita; l'albero è facile da disegnare in quanto non può mai essere modificato, puoi letteralmente aggiungere roba tutto il tempo. È possibile effettuare una sessione di gioco in un repository locale appena creato e utilizzare git cat-fileper esaminare gli oggetti reali per mostrare loro che in realtà sono banali come pubblicizzati.

Se puoi aiutarli a capirlo

• ... ci sono letteralmente solo 3 tipi di oggetti nella storia, tutti molto semplici, quasi banali e
• ... la maggior parte dei gitsottocomandi semplicemente "massaggia" quegli oggetti in un modo o nell'altro, con operazioni quasi banali (in pratica, ce n'è solo uno: aggiungi un nuovo commit da qualche parte), e ...
• ... tutto può essere facilmente visto di fronte a te con lse git cat-file...

quindi avranno la traduzione mentale di ciò che è effettivamente nel repository. A questo punto, i seniouri potrebbero ricordare che gli interni di svnsono magie arcane ( hai mai avuto problemi con le serrature all'interno del repository svn, o con rami "reintegranti" e simili?), E questo potrebbe solo motivarli un po '.

Un problema, in particolare con chi è abituato a svn, è quello di abituarsi all'idea che un commit (l'oggetto, non l'azione) sempre è tutto l'albero di directory. In svn, le persone vengono utilizzate per eseguire il commit di singoli file. È un approccio radicalmente diverso. Oh, e il fatto che lo stesso termine "commit" sia usato sia per un oggetto statico che per un'azione non aiuta neanche.

L'altro problema per i svnragazzi è che svnusa una storia lineare, non un albero. Questo è, ancora una volta, molto diverso. Quindi questo è il momento di puntare di queste differenze molto .

Azioni spiegate in termini di struttura

Quando hanno capito da quali parti gitè composto un repository, è tempo di mostrare loro esattamente cosa fanno i singoli gitsottocomandi in termini di quelli.

Sto parlando add, commitinsieme alla directory di lavoro locale e allo stage (assicurarsi che comprendano che la directory di lavoro non è la stessa dell'area di gestione temporanea che non è la stessa del repository).

Quando hanno capito che questi comandi fanno semplicemente crescere l'albero (che, di nuovo, in questa fase, è costituito da 3 tipi: macchie, alberi, commit, non solo commit), puoi fare un primo git pushe git pull(in modalità avanzamento veloce! ) per mostrare loro che gitsta letteralmente solo spingendo i suoi oggetti in giro, che gli hash sono in realtà solo hash di contenuto, che puoi facilmente copiare queste cose con un comando di copia del file system e così via.

Ovviamente, stai lontano da qualsiasi opzione non essenziale di quei comandi, stiamo parlando git add hello.txtqui.

filiali

Si noti che la ramificazione è particolarmente difficile per le svnpersone, poiché è totalmente diversa. Il svnmodello è molto più facile da visualizzare, poiché praticamente non c'è nulla da visualizzare: è in bella vista. Il gitmodello non è così tanto. Assicurati che siano consapevoli fin dall'inizio che rami e tag sono solo "note adesive" che puntano da qualche parte, e in realtà non "esistono" in termini di storia statica, immutabile.

Quindi fai un esempio dopo l'altro per mostrare cosa puoi effettivamente fare con loro. Come sembra che tu stesso ti sia abituato git, non dovresti avere problemi a trovare motivazione lì. Assicurati di vederlo sempre in termini di come l'albero cresce.

Se hanno questo verso il basso, puoi spiegare come git pullè realmente git fetch && git merge; come tutti i repository contengano esattamente gli stessi oggetti ( git fetchè quasi lo stesso della copia di oggetti scpall'interno della directory degli oggetti git) e così via.

Probabilmente, se a questo punto non hai raggiunto per suscitare il loro interesse, allora puoi anche rinunciare, ma se riescono ad arrivare così lontano, allora hanno tutti gli strumenti mentali a loro disposizione e dovrebbero esserci pochi la paura è più coinvolta. Il resto (flusso di lavoro git ...) dovrebbe essere in discesa allora.

Ultime parole

Sembra un grande sforzo, e lo è davvero. Non venderlo come "ne abbiamo bisogno per questo progetto" ma "questo ti aiuta a sviluppare personalmente e ti aiuterà in tutte le tue ulteriori interazioni". Hai bisogno di molto tempo per questo, e il tempo è denaro. Se non si ha l'accettazione da parte della direzione, potrebbe non valerne la pena; dovresti forse parlarne con il tuo capo.

Se decidi di voler smettere di insegnare agli sviluppatori che apparentemente non sono in grado di afferrarlo, ma devi assolutamente usarlo gitin futuro, considera la possibilità di sostituire tutte le interazioni con i gitcomandi con script elaborati o alcune GUI che tolgono tutti i gitdettagli. Versare tutto il controllo degli errori ecc. Negli script e provare a farlo funzionare.

Vorrei fare riferimento a questo post di blog di Joel Spolsky .

Il motivo che stai vedendo per questi sviluppatori junior che lo raccolgono rapidamente è molto probabile perché non hanno una nozione predeterminata su come funziona il controllo delle versioni in generale, o almeno non un modello mentale così profondamente radicato. Come tali, entrano con una lavagna pulita. I tuoi programmatori più anziani stanno probabilmente cercando di applicare i concetti che già conoscono e, di conseguenza, non riescono.

Inoltre, per quanto non mi piace dirlo; chi legge effettivamente i manuali utente? In genere sono molto cattivi nello spiegare l'uso di base. Basta guardare la pagina di commit git dal manuale e considerare quanti nuovi termini e frasi vengono introdotti a qualcuno che non è al passo con il concetto. Senza una buona introduzione probabilmente avrei rinunciato a usare Git proprio lì e poi.

Il mio consiglio personale sarebbe quello di iniziare a spiegare i comandi:

• git aggiungere <file>
• git commit
• git pull
• git push
• stato git

L'unione logica dei conflitti dovrebbe essere spiegata in seguito, perché questo sarà sicuramente il tuo primo problema una volta che le persone impareranno a impegnare il codice.

In genere si verificano situazioni in cui le persone dovranno investire più tempo nell'apprendimento di cose (ripristini, tag, unire conflitti, rami, rebasing, hook), ma cercare di spiegare tutto ciò prima che sia necessario non aiuterà le persone che hanno problemi ad entrare il flusso.

Solo per concludere: dalla mia esperienza personale alcune persone semplicemente non passano molto tempo a esplorare nuove tecniche, concetti o strumenti e in genere tendono a raccogliere le cose a cui li introduci a un ritmo più lento. Ciò non significa che siano cattivi programmatori o cattive persone, ma in genere hanno un set di abilità più ristretto.

Git è un grande ripensamento se hai imparato a fare il controllo del codice sorgente su SVN. Molte delle abitudini che hai sviluppato lì (che potrebbe essere stata la migliore pratica per SVN) ti guideranno male quando usi Git. Ciò è dovuto principalmente al fatto che il modello di ramificazione di Git è fondamentalmente diverso. Non sfrutta le cartelle per i rami ed è anche possibile renderlo non lineare perché progettato per supportare meglio i casi d'uso distribuiti. Ci vuole del tempo per disimparare le abitudini SVN e capire come dovresti usare git.

Inizia semplice

Dici di aver scelto Gitflow come standard per la gestione delle filiali. Questo mi sembra il tuo più grande errore.

Per citare Gitflow considerato dannoso :

Tutti questi rami usati costringono GitFlow ad avere un insieme elaborato di regole complicate che descrivono come interagiscono. Queste regole, unite alla storia immateriale, rendono molto difficile l'utilizzo quotidiano di GitFlow per gli sviluppatori.

Riesci a indovinare cosa succede ogni volta che crei una complessa rete di regole del genere? Esatto: le persone commettono errori e li rompono per caso. Nel caso di GitFlow, questo accade sempre. Ecco un breve elenco non esaustivo degli errori più comuni che ho osservato. Questi vengono ripetuti costantemente, a volte ogni giorno, spesso ripetutamente dagli stessi sviluppatori, che nella maggior parte dei casi sono molto competenti in altre aree software.

I tuoi sviluppatori sono probabilmente sopraffatti dalla pura complessità di questo standard. Personalmente non penso che abbia alcun vantaggio e l'articolo sopra fa lo stesso argomento. Ma questa è una discussione separata. Obiettivamente, tuttavia, è uno standard piuttosto pesante con molta gestione manuale e richiede molto sforzo cognitivo.

Devi iniziare più semplice. Non preoccuparti di uno standard di ramificazione in questo momento. Concentrati su come abituarli a usare prima git . Per iniziare sono necessarie solo alcune operazioni:

• clone
• Tirare
• ramo
• fondersi
• commettere
• spingere
• conoscenza di come .gitignorefunziona
• forse tag

Sì, la tua storia potrebbe sembrare un po 'disordinata all'inizio. Questo va bene. Non ti preoccupare adesso. Basta farli usando git .

Aumentare gradualmente la conoscenza

Da qui, puoi educarli gradualmente su un uso leggermente più avanzato.

• Insegna loro il comando epico di scorta
• Insegnate loro come utilizzare il reset quando vogliono buttare via il commit locale che hanno appena fatto
• Insegna loro come modificare
• Insegnate loro come rifare per evitare impegni di unione non necessari
• Insegnate loro come rifarsi interattivamente per organizzare i loro impegni prima che spingano
• Insegna loro come possono effettuare il checkout da qualsiasi hash, tag o ramo

Soprattutto assicurati di sfruttare le opportunità per mostrare loro modi più puliti per ottenere il loro codice nel repository, ma insegna anche queste cose nelle attività di formazione e cosa hai. Avere un guru o due a cui le persone possono avvicinarsi quando non sono sicuri di cosa fare aiuterà molto. Se hai qualcosa come Slack, crea un canale dedicato e incoraggia le persone a porre e rispondere alle domande lì.

Quindi scegli uno standard di ramificazione

Una volta che avete la maggior parte della società competente utilizzando git a tutti, allora si può guardare gli standard di diramazione. Scegliere uno in anticipo è una pessima idea per diversi motivi:

• Non hanno abbastanza conoscenza dello strumento per dirti se lo standard funziona bene per i casi d'uso dell'azienda
• Non saranno in grado di offrire standard alternativi
• Devono imparare sia lo strumento che lo standard allo stesso tempo
• Alcuni supporranno che lo standard scelto sia l'unico modo in cui possono usare git
• Non saranno in grado di identificare rari casi limite in cui lo standard sta facendo più male che bene

Non dovresti tramandare un flusso di lavoro Git dalla montagna. Il tuo team deve avere input su di esso ed essere in grado di darti un feedback se sta andando bene o no. Non possono farlo se non capiscono ancora i fondamenti. Non hai bisogno che ogni singolo sviluppatore abbia una conoscenza approfondita come questa, ma hai sicuramente bisogno di molti che lo capiscano davvero. E hai bisogno della stragrande maggioranza di essere almeno competente in git in modo che sappiano abbastanza per stare un po 'sui binari.

Ecco un paio di alternative a Gitflow che il tuo team può prendere in considerazione:

• OneFlow
• Flusso di lavoro del ramo delle caratteristiche
• Flusso di lavoro centralizzato

Guardali e Gitflow, confrontali con i tuoi casi d'uso e scegline uno adatto.

Ho trovato molto utile stackoverflow mentre stavo raccogliendo la terminologia Git. Domande come queste sono state davvero utili per me (principalmente a causa della loro concisione) e le ho tenute aperte nelle schede durante le prime due settimane che l'ho usato. Forse stampare un paio di risposte in grassetto? Soprattutto il diagramma sul primo.

Quali sono le differenze tra "git commit" e "git push"?

Qual è la differenza tra 'git pull' e 'git fetch'?

Ho anche trovato una rappresentazione visiva del tronco incredibilmente utile, ma stai già coprendo quella con SourceTree.

_{A parte, questo bit probabilmente appartiene a un commento, ma mi manca il rappresentante: sono uno dei consulenti junior menzionati nella domanda. Prima di iniziare, avevo la minima idea di cosa fosse un sistema di controllo del codice sorgente e avevo letteralmente colpito SVN due volte, Gusdor mi ha dato più credito di quanto meriti. L'intero team ha avuto formazione Git specializzata di alta qualità, giocattoli e tempo per giocare. Il problema non è con le istruzioni di Gusdor. Spero che ci sia una buona soluzione alternativa a questo in modo da poterlo aggiungere ai segnalibri e imparare di più.}

Compra loro un libro

Onestamente, sono caduto esattamente nel campo che descrivi. Vengo da uno sfondo di SourceSafe e ClearCase. All'inizio, Git era completamente imperscrutabile per me, nonostante il mio capo lo attraversasse più volte.

Ciò che mi ha aiutato è stato un libro che descriveva chiaramente cosa stava succedendo, ma soprattutto, come Git era fondamentalmente diverso da qualsiasi sistema di controllo del codice sorgente che avevo usato prima. Ora preferisco Git rispetto a qualsiasi altra scelta.

Sfortunatamente, non riesco a ricordare quale libro avevo letto in quel momento, ma, assicurati solo che quello che ottieni per loro (o indicandoli) si concentri su come è diverso e su come richiede una diversa mentalità.

La migliore ipotesi per una raccomandazione di un libro è:

Pro Git di Scott Chacon (link Amazon per facilità ... acquista da chi vuoi: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Nota : non acquistare un libro di consultazione per Git. Questo non aiuterà affatto.

Dalla mia esperienza, alcune persone possono sentirsi a proprio agio con Git senza capirlo. Trovano tutorial di base, raccolgono comandi di base e sono pronti a partire. Questo è probabilmente il posto adatto a voi consulenti junior. Non credo che tu possa davvero imparare git in pochi giorni!

Altre persone, non possono farlo, hanno bisogno di capire cosa sta facendo git e questo richiede più tempo. Ero in quella categoria; Ho trovato davvero utile giocare con i contenuti della .gitdirectory, in quel momento le cose hanno iniziato a fare clic per me. Anche le sessioni individuali con il nostro responsabile tecnico ci hanno aiutato.

Puoi fare uno su uno tutorial perché le persone imparano in modo diverso e possono essere davvero confusi su parti diverse, in una sessione uno a uno è più facile da vedere e risolvere. Se sono davvero infastiditi dal fatto che non capiscono come git tiene traccia dei rami, mostra loro il contenuto della .gitdirectory e così via ...

Sto giocando con l'introduzione di gitdove mi trovo (da TFS), quindi la tua domanda è tempestiva per me, soprattutto perché ho anche avuto qualche respingimento quando ho affrontato l'argomento.

In Peopleware , le tesi sottostanti dell'intero libro sono:

I maggiori problemi del nostro lavoro non sono tanto tecnologici quanto di natura sociologica .

Lo sollevo perché il nostro non è un problema tecnico. git, sebbene un po 'ottuso, probabilmente non è al di là delle tue capacità o dei miei sviluppatori senior, a meno che non siano estremamente stupidi *.

Vediamolo dal punto di vista degli sviluppatori, in quanto persone, non macchine tecniche:

Stai chiedendo loro di smettere di usare un sistema di controllo del codice sorgente di cui hanno (probabilmente) padronanza, a uno che non possiedono. È un po 'come chiedere a un gitesperto di smettere di usare gite passare a svnnon è vero? Credo che l'esperta di git sarebbe infastidita, e probabilmente non farebbe molti sforzi svnperché gitfunziona bene e ci sono parti in cui le piace davvero che sono davvero difficili da fare svn.

Questo è probabilmente il motivo per cui i junior ci hanno preso meglio - forse non hanno capito svne gitc'è la loro possibilità di abbandonarli ^.

Gli anziani però diffidano del costo opportunità - se imparano git, allora non lo sono:

• Learning React / Angular / Swift / Blockchain / Kotlin (qualche altra cosa che sentono di dover imparare).
• Fare fai-da-te / whittling / vela / poesia / glockenspiel / qualunque altra cosa vogliano realmente fare.
• Trascorrere del tempo con i loro figli / parenti / amici / altri significativi.

• Fornire questa "grande novità" - c'è una scadenza, un budget ecc. Probabilmente sono preoccupati.

  "Devo fare tutto quanto sopra, perché devo usare git quando abbiamo già il controllo del codice sorgente?"

Quali motivi hai dato loro per passare da una cosa in cui sono bravi a un'altra cosa che è francamente imbarazzante quando sei nuovo e che richiede un ripensamento completo su come fai lo sviluppo? Hai spiegato i vantaggi delle gitfunzionalità?

Pull-richieste? Check-in a grana fine? Fonte distribuita? Forchette?

Hanno portato a questi motivi? Si tratta di enormi cambiamenti strutturali se ci si trova in una mentalità centralizzata di controllo delle fonti - non solo cambiamenti tecnici ma anche culturali, e sappiamo quanto sia difficile cambiare una cultura.

Quindi, in sostanza, pensa a cosa stai chiedendo ai tuoi sviluppatori di fare e assicurati che sia per le giuste ragioni. Se vuoi semplicemente farlo perché svnè stupido e vecchio e nessuno lo usa più, va bene, ma è più difficile venderlo ad altri che non pensano come te e vogliono solo continuare con la loro giornata. Devi dichiarare i vantaggi in termini che hanno senso per il tuo team e per il progetto. Se riesci a convincerli che gitvale la pena, non devi preoccuparti che apprendano la tecnologia, accettando semplicemente il flusso di lavoro che hai impostato.

In bocca al lupo.

Penso che sia meno una questione di ingegneria del software e più una questione di psicologia. Mi piacerebbe fare riferimento a Algorithms to Live By: The Computer Science of Humand Decisions. In esso l'autore affronta l'argomento del compromesso esplora / sfrutta. Gli umani di solito attraversano una fase di esplorazione e poi attraverso una fase di sfruttamento (usando) ciò che hanno esplorato. C'è una solida teoria matematica dietro perché questo è il caso per ottenere un uso ottimale di qualcosa in un certo intervallo.

Questo si estende anche all'età e all'esperienza. Gli umani vedono la propria vita come un intervallo e dopo una certa fase di esplorazione è ottimale iniziare a usare le tue conoscenze. Hanno citato uno studio in cui ai partecipanti più anziani è stato chiesto se volevano incontrare qualcuno famoso che a loro piace o piuttosto un membro della famiglia. Di solito hanno scelto il membro della famiglia, mentre i più giovani hanno scelto la persona famosa più probabilmente. Tuttavia, quando gli viene chiesto di immaginare come avrebbero deciso se fossero 20 anni più giovani, le persone anziane hanno scelto di routine anche la persona famosa. Il che suggerisce che le persone smettono di costruire i loro social network quando credono di avere meno dall'esplorazione che dallo sfruttamento di ciò che già sanno.

I tuoi ingegneri senior sono probabilmente più anziani, hanno probabilmente attraversato alcuni sistemi di controllo della versione. SVNè probabilmente il migliore che abbiano usato finora (almeno guardando i vecchi sistemi di versioning che ho usato, SVN li ha battuti tutti).

La loro strategia ottimale è quella di sfruttare SVN, perché hanno fatto la loro esplorazione e hanno scoperto che questo è il migliore, che sfruttano ora.

Questa è la psicologia umana di base e centinaia di migliaia di anni di ottimizzazione evolutiva contro cui stai combattendo.

Dovrai mostrare loro a) per quanto tempo hanno una carriera davanti a loro, per prepararli a pensare da una prospettiva diversa sull'intervallo in cui si vedono eb) chiedere loro cosa pensano sia grandioso e cosa ' ti manca in SVN. Puoi disporre di centinaia di vantaggi git, ma avranno già una chiara idea del perché SVNsia il migliore, dopo tutto hanno già sperimentato probabilmente 5 sistemi di controllo della versione prima. Devi trovare la crepa nell'armatura di quell'argomento, e poi vedere se gitpuò risolvere questi problemi, quindi si saranno convinti.

Non dare loro uno strumento o una GUI per usare Git. Confonderà solo le cose. Git è stato concepito per funzionare su una riga di comando in modo che probabilmente dovrebbe essere il posto in cui viene appreso. Ogni interfaccia grafica può venire con i suoi termini e le sue peculiarità, attenersi a ciò che è semplice.

Il prossimo sarebbe quello di esaminare alcuni dei problemi che Git fa meglio di SVN. Per far sì che il tuo team lo impari, devi motivarli per capire perché Git è migliore.

• Capacità di impegnarsi quando non si è connessi alla rete
• Capacità di creare e giocare con i propri rami
• Patch che possono essere inviate tra loro e uniscono ancora la traccia
• raccolta delle ciliegie senza dolore.
• cambiare le modifiche
• trovare bug con git splice

Sono sicuro che SVN è andato avanti negli ultimi anni, ma quelli erano cose che causavano un mondo di dolore. Se gli sviluppatori vedono che questo nuovo strumento non è solo una cosa stravagante, ma presenta solidi vantaggi per il loro lavoro, è più probabile che ce la facciano.

È una cosa nuova da imparare e ci sono abbastanza somiglianze che possono creare confusione, ma davvero nel 2017 DCVS è praticamente un'abilità essenziale per ogni sviluppatore.

Di 'loro di non preoccuparsi

In Git, una volta che il lavoro è impegnato, è quasi impossibile perdere. L'unico lavoro che puoi facilmente perdere è il lavoro che non è stato ancora impegnato.

Mostra loro come git reflogfunziona. Non devono saperlo usare; hanno solo bisogno di sapere che è lì, quindi possono ottenere aiuto per riprendere il loro lavoro se qualcosa va storto.

Quindi impressiona con loro questa semplice regola: in caso di dubbio, impegnati. Possono sempre annullare il commit in un secondo momento (anche dal telecomando!).

Non usare una GUI

Una GUI darà loro un inizio più veloce, ma non capiranno mai davvero Git. Inoltre, ho scoperto che non è "quasi impossibile perdere" il lavoro impegnato quando si utilizza una GUI Git. Ho visto le GUI fare cose orribili come presentare un elenco di controllo all'unione e quindi, se l'utente deseleziona un elemento, cancella quel file dalla cronologia senza preavviso e nessun record di esso. Una GUI è molto peggio del semplice apprendimento della riga di comando Git.

Commette il codice del programma di coppia

L'apprendimento git add -Aseguito git commitnon dovrebbe essere troppo difficile, ma in particolare quando si uniscono (o si riformano) contro il telecomando, avranno bisogno di assistenza. Metti in chiaro che chiunque è invitato a chiedere assistenza in qualsiasi momento. Resta in attesa mentre digita i comandi e prende appunti. Nel tempo aumenteranno gradualmente il numero di situazioni che possono gestire senza aiuto.

Git è già al sicuro

Qualcuno sopra ha parlato di "un posto sicuro dove giocare". Ma Git è quel posto sicuro. Esistono solo due casi normali di tutti i giorni in cui è facile perdere il lavoro:

• Codice non confermato
• Utilizzando una GUI

Assicurati che si impegnino presto e spesso e che non inizino a seguire un percorso sbagliato con una GUI e vedranno presto che in passato potranno fidarsi di Git con il loro codice anche più di altri sistemi di controllo del codice sorgente.

Consiglierei uno sguardo a Gitless . È un wrapper su git che semplifica molto il flusso di lavoro di base (non è necessario preoccuparsi di un'area di gestione temporanea, i rami mantengono le proprie copie di lavoro dei file, gli usi più semplici git rebasevengono gestiti con gl fuse, ecc.) Mantenendo un repository git sottostante per la collaborazione o se devi fare qualcosa di insolito. Inoltre, i messaggi sono un po 'più adatti ai principianti. E i comandi sono abbastanza vicini da git da agire come trampolino di lancio se hanno bisogno di usare un sistema senza gitless su di esso per qualsiasi motivo.

Ho provato a documentare le basi di come usare la riga di comando di git. Era ancora confuso - sia per me stesso (che aveva esperienza nell'uso di Perforce e Source Safe), sia per i programmatori che preferivano il vecchio paradigma "comprimere solo le cartelle rilevanti". Era preoccupante avere uno strumento opaco per modificare il contenuto della mia directory di lavoro e spesso dover discutere con lo strumento per incorporare particolari cambiamenti nella mia directory di lavoro.

Invece, uso due tipi di indiretta.

• Uso GitKraken per fornire una cronologia visiva dei miei rami e una GUI che nasconde le istruzioni della riga di comando. GitKraken gestisce le interazioni tra il repository remoto "origin" e quella che git pensa sia la mia directory di lavoro locale.

• Tengo anche una "vera" directory di lavoro locale che è separata da quella che Git pensa sia la mia directory di lavoro locale. Sincronizzo manualmente queste due directory di lavoro, il che mi consente di sentirmi molto più a mio agio che qualsiasi modifica nella mia directory di lavoro è ciò che intendevo avere.

C'è qualcosa che posso fare per aiutare questi dipendenti ad imparare Git?

Sei sicuro che il problema sia Git e non qualcos'altro? Quello che ottengo dal commento è che la direzione ha deciso di cambiare qualcosa senza ricevere acquisti dai contributori senior e sta incaricando qualcuno di loro di guidare il cambiamento. Sembra un buon punto di partenza per il fallimento, qualunque sia il cambiamento. La complessità di Git non è un problema, il problema è che un cambiamento di cui non sentono il bisogno è imposto su di loro.

Quindi non concentrarti su come insegnare loro Git, finché non vedranno un vantaggio per l'interruttore che trascineranno i loro piedi. Mostra loro come Git è una soluzione ai problemi che hanno ora. Non come Git può fornire loro cose di cui non sentono ancora bisogno, non come Git fornisce una soluzione ai problemi di altre persone, come Git risolve i problemi che stanno combattendo ora. Quindi insegnare loro Git non sarà un problema.

Spesso Git viene utilizzato in un'azienda per risolvere problemi con le filiali. Sì, è meglio ai rami di Subversion, ma non fa alcuna magia.

È molto probabile che gli sviluppatori esperti abbiano lavoro in molte aziende che hanno.

• Le filiali create in quanto la direzione non è disposta a decidere tra richieste contrastanti
• Hanno utilizzato una filiale per ogni cliente anziché switch di configurazione.
• Ho dovuto disporre di un ramo per la correzione di bug per ciascun cliente poiché la direzione non era disposta a fare in modo che tutti i clienti aggiornassero alla stessa versione del software
• Eccetera.

Pertanto non appena alcuni mi dicono che uno strumento è bravo a ramificare la mia mente mi dice.

Il management non vuole decidere in che direzione sta andando la società, e preferirebbe che io sprecassi la vita dovendo unire il mio lavoro in 101 diverse filiali, oltre a dover testare 101 diverse versioni del software.

Anche il concetto che due persone lavorerebbero sullo stesso file nello stesso è "buono", non è accettabile per qualcuno che ha vissuto un progetto ben gestito, quindi è improbabile che venga sperimentato Git come strumento per farlo. gli sviluppatori ti piacciono.

Ogni volta che guardo la storia in Git, è molto difficile capire perché il codice è cambiato, poiché il 50% o più della storia si fonde che logicamente non avrebbe mai dovuto essere pubblico e diventano insignificanti non appena il codice lascia gli sviluppatori macchina.

Ma mi piacerebbe lavorare da qualche parte dove:

• Nessun codice entra nel sistema centrale fino a quando non viene compilato e testato l'unità su un server fidato.
• C'è un modo semplice per tenere traccia delle recensioni dei codici
• Dove ogni volta che faccio un "get", il codice viene sempre compilato e funziona
• Dove posso spingere i miei cambiamenti senza dover gareggiare con qualcun altro, o dover vagare in ufficio per vedere se ho rotto la build.

Quindi risolvi i problemi reali e se Git fa parte delle soluzioni in cui i tuoi sviluppatori esperti compreranno, ma non aspettarti che Git piaccia loro solo perché è un bel giocattolo che può fare "fusioni magiche".

Pertanto, ovunque ciò che consente a uno sviluppatore di passare dal proprio Git locale al Git centrale, lo fa in modo sbagliato, un processo automatizzato controllato dovrebbe prendere le modifiche dagli sviluppatori e dopo averle testate ecc. filiali ecc. che non sono di interesse a lungo termine.

Mi aspetto che Kiln ( http://www.fogcreek.com/fogbugz/devhub ) o anche GitHub utilizzando un flusso di lavoro di "richiesta pull" renderebbero felici gli sviluppatori esperti, ad esempio non iniziare con il basso livello preso, iniziare con il miglioramento processi.