Il nuovo sviluppatore non riesce a tenere il passo con le fusioni di filiali

Sono il nuovo sviluppatore: questa è la mia prima posizione di programmazione.

Il mio problema è questo: usiamo git: ho tagliato un ramo dal nostro developramo, quindi ho iniziato a lavorare sull'attività minore che mi è stata assegnata. È molto lento, perché sono inesperto. Quando sono pronto a ricollegare il mio ramo agli developaltri, ho apportato così tanti cambiamenti che la risoluzione dei conflitti è schiacciante (in realtà sembra più facile scartare il mio lavoro e ricominciare il compito, che ovviamente non è una soluzione sostenibile ).

Come posso superare questo? Esiste una tattica che posso usare oltre a "essere più bravo a programmare"? Ho intenzione di parlarne con il mio supervisore la prossima settimana.

Si verificano conflitti di unione se le modifiche apportate al proprio ramo sono vicine alle modifiche che i colleghi hanno fatto nel developramo nel frattempo, vale a dire se tu e i tuoi colleghi avete modificato le stesse linee di codice o le linee adiacenti nello stesso file.

Quindi, per ridurre la probabilità di unire i conflitti, puoi provare a unire prima in modo che i tuoi colleghi abbiano cambiato meno linee nel frattempo, oppure puoi provare a cambiare meno linee tu stesso.

Per modificare manualmente meno righe, assicurati di apportare solo modifiche relative alla tua attività.

Se hai bisogno di sperimentare modi diversi per raggiungere il tuo obiettivo, forse alcuni dei tuoi esperimenti hanno cambiato le linee che non hanno davvero bisogno di essere cambiate? Annulla queste modifiche prima di unirle.

Ci sono anche alcuni comandi Git che possono aiutarti a cambiare il minor numero di righe possibile:

• git diffe git diff --stagedper vedere quali linee hai cambiato.
• git add -p per aggiungere solo alcune delle modifiche in un file.
• git commit --amende git rebase -iper modificare i commit già effettuati nel ramo delle funzionalità locali prima di trasferirli in altri repository Git.

(Cambiare il minor numero di linee come possibile può anche rendere più facile vedere il vostro lavoro o di utilizzare strumenti che funzionano sulle differenze tra i quali si impegna git cherry-pick, git rebase, git bisect, e git blame.)

Ma anche se riduci la probabilità di unire conflitti, a volte incontrerai comunque conflitti di unione. Quindi non aver paura di loro, ma impara come risolvere i conflitti.

Presumo che tu stia usando git. In tal caso, utilizzare git rebase -i(il -imezzo interattivo). Renderlo un compito quotidiano (anche più frequentemente, se necessario) per riordinare il ramo contro il ramo di sviluppo. Questo porta le modifiche in modo incrementale ogni giorno (almeno) per mantenere aggiornato il ramo delle funzionalità. Se ci sono conflitti durante il rebase quotidiano, devi parlare con il tuo team su chi sta lavorando su cosa.

Se lo esegui quotidianamente, probabilmente non avrai bisogno della parte interattiva. Lascia che faccia le sue cose.

Sono uno sviluppatore abbastanza esperto e mi ci vuole ancora un bel po 'di tempo per mettermi al passo con un nuovo progetto. Nel tuo caso, sembra che tu abbia diverse persone che lavorano allo stesso progetto contemporaneamente, quindi è un progetto molto grande o un nuovo progetto che si sta evolvendo rapidamente. In entrambi i casi, non preoccuparti se ti ci vogliono diversi mesi per entrare nel flusso. Se cambio progetto per 2 o 3 settimane e poi torno indietro, possono volerci alcune ore (o anche un giorno o due) per tornare completamente "in" un progetto che ho scritto al 100% da solo!

In breve, non preoccuparti di essere lento in questo momento. Il modo per migliorare è semplicemente continuare a praticare. Non abbiate paura di chiedere ad altri sviluppatori aspetti dei progetti che non capite.

MODIFICARE:

Oppure usa merge. Anche questa è un'opzione. Quindi, quanto sopra sarebbe: "utilizzare git rebase -i(i -imezzi interattivi) o git merge". Per quanto riguarda quale usare, parlane con il resto della tua squadra. Possono (o no) avere preferenze forti in entrambi i modi. E 'chiaro che alcune persone non hanno preferenze forti.

Questo potrebbe essere un segno di cattiva ingegneria del software da parte dell'azienda. Troppe interdipendenze, problemi diversi con funzioni sovrapposte, tentando di affrontare i problemi nell'ordine sbagliato ecc. Possono causare la situazione che stai descrivendo. Suggerisco di fondersi regolarmente developnella tua filiale durante lo sviluppo

Le risposte accettate penso che siano più di natura tecnica "come usare Git meglio", penso che questo sia più un problema di squadra che un problema di ingegneria o strumentazione.

Se stai incontrando molti conflitti di unione, significa che tu e qualcun altro del team state calpestando le dita dei piedi.
Dovresti mirare a sviluppare lo spazio personale durante la codifica ed evitare di lavorare in aree che sono già occupate.

Nella mia squadra, tendiamo ad un alto grado di responsabilità.
Di solito prenderò la piena e completa proprietà di due o tre file alla volta e lavorerò su di essi in un ramo per un giorno o due al massimo.
In genere se qualcun altro tocca quei file è solo se assolutamente necessario per i propri compiti, generalmente non lavoriamo affatto sullo stesso blocco di attività!

Se stai scoprendo che devi unire molto, allora tutto il codice del tuo team è in un posto (cosa che è qualcosa da evitare in sé) o tutti i tuoi compiti.

Detto questo, come nuovo sviluppatore probabilmente non sei in grado di imporre, richiedere o addirittura suggerire davvero qualsiasi tipo di ristrutturazione.
Quello che mi aspetterei è che i tuoi compiti siano stati assegnati come elementi "impara le corde" che dovrebbero essere ragionevolmente accessibili al tuo livello di abilità al fine di facilitare te nel team. Probabilmente sono stati eliminati dai compiti di un collega che sta ancora lavorando nella stessa area, quindi i tuoi conflitti di unione.
La soluzione a questo è quindi di risolverlo, risolvere i problemi, gestire i conflitti di unione nel miglior modo possibile e non preoccuparti troppo, finché fai del tuo meglio, spetta al tuo manager preoccuparti i tuoi progressi.
Otterrai più veloce e più sicuro mentre vai,

La cosa più importante della fusione è che più a lungo aspetti, più diventa doloroso. E il problema cresce più che lineare. Tre volte più conflitti sono nove volte più lavoro. Ci sono alcune strategie:

Unisciti al ramo di sviluppo ogni volta che cambia, quindi sei sempre vicino ad esso e non hai mai un numero enorme di conflitti.

Se impieghi molto tempo, potrebbe essere perché passi la maggior parte del tempo a capire quali sono le modifiche e quindi una piccola quantità di tempo per implementarle. In tal caso, unire con il ramo di sviluppo prima di iniziare le effettive modifiche al codice.

Parla con i tuoi colleghi delle strategie per evitare conflitti. Si verificano conflitti se due persone modificano lo stesso codice. Non solo lo stesso file, ma lo stesso codice. Quindi ho bisogno di una nuova funzione A e tu hai bisogno di una nuova funzione B, e la aggiungiamo entrambe alla fine dello stesso file, abbiamo un conflitto. Se lo aggiungiamo in luoghi diversi, nessun conflitto. Se lo aggiungiamo entrambi in un punto del file in cui appartiene logicamente, è probabile che non ci siano conflitti.

In caso di conflitti, ottenere un buon strumento diff, in modo da poter confrontare il ramo di sviluppo prima dell'unione, il codice prima dell'unione, il codice originale e il codice unito e unire manualmente.

Caso peggiore: non buttate via il vostro lavoro, ma utilizzate un buon strumento diff per scoprire esattamente quali modifiche avete apportato, ramificate di nuovo dallo sviluppo e applicate tutte le modifiche apportate manualmente invece di riscriverle.

Con il tempo sono pronto a fondersi mio ramo di nuovo in sviluppo (sottolineatura mia)

Gestire i conflitti in git mergeè spesso più semplice che in git rebase. In Git Merge puoi vedere l'intero elenco di file che sono stati modificati contemporaneamente. Non importa quanti impegni sono stati fatti da altri colleghi, dovrai unirti una volta . Con il flusso di lavoro rebase, potresti finire per ottenere sempre gli stessi conflitti e doverli rivedere manualmente. Puoi finire per risolvere il 13 ° commit e sentirti come se non riuscissi a vedere la luce fuori dal tunnel .

In base alla mia esperienza, quando ho tentato di risolvere ingenuamente ripetuti conflitti di rebase, ho finito per perdere le modifiche di qualcuno o con un'applicazione che non è stata nemmeno compilata. Spesso io e i colleghi abbiamo lavorato molto, ma siamo stati così sopraffatti dalla complessità dei conflitti ripetuti che abbiamo dovuto interrompere e perdere il nostro lavoro precedente dopo una manciata di impegni di rebase.

Ti suggerirò alcune tecniche, ma possono solo aiutare l'unione a diventare più facile che automatizzare l'attività.

• File di risorse / lingua . Se sono presenti modifiche aggiuntive a un file di risorse, assicurarsi di spostarle sempre alla fine del file in modo da poter richiamare facilmente le modifiche rispetto alle modifiche altrui . Potresti essere in grado di copiare e incollare le modifiche sul fondo o semplicemente rimuovere i contrassegni di conflitto
• Fare. Non. ASSOLUTAMENTE. Formato RE . Né tu né i tuoi colleghi sviluppatori dovrete eseguire un "massiccio riformattamento del codice" durante il lavoro quotidiano. La riforma del codice aggiunge un numero eccessivo di falsi positivi nella gestione dei conflitti. È possibile eseguire la riformattazione del codice
  • Incrementalmente, ad esempio da ogni sviluppatore su ogni commit, non appena utilizzano uno strumento automatizzato (ad esempio Eclipse ha un'opzione per riformattare il salvataggio, Vanilla Visual Studio non ne ha). Assolutamente ogni sviluppatore deve utilizzare gli stessi standard di formattazione del codice, codificati in un file di formato che viene mangiato dal tuo IDE. Per darti un'idea, se sono 4 spazi o 2 schede non importa, ma importa davvero se tutti usano lo stesso.
  • Poco prima del rilascio, da un capo squadra. Se si verifica un commit di "riformattazione del codice" quando le persone non lavorano sui rami, cioè prima che si ramifichino, le cose renderanno più facili
• Rivedi il lavoro diviso tra colleghi. Questa è la parte in cui arriva la maggior parte dell'ingegneria. Come indicato da altre risposte, è odore di design se più sviluppatori che svolgono attività diverse devono toccare le stesse risorse. Potrebbe essere necessario discutere con il team leader su quale parte deve essere modificata da ogni sviluppatore simultaneo.

Ho anche visto alcune cattive abitudini nei flussi di lavoro di Git nei miei team. Spesso le persone si sovraccaricano nei loro rami. Ho assistito personalmente a uno sviluppatore che ha aggiunto da 10 a 20 commit etichettati "fix", ciascuno dei quali ha commesso una o due righe. La nostra politica è che gli commit siano etichettati con i biglietti JIRA per darti un'idea.

@JacobRobbins suggerisce di svolgere git rebaseun'attività quotidiana. Vorrei spingere in avanti il ​​suo approccio.

In primo luogo, utilizzare rebase una volta solo per ridurre il numero di commit a una manciata. E rifa solo sul ramo di sviluppo originale , che è il commit da cui ti sei ramificato. Quando dico manciata, potrei significare 3 o 4 (ad esempio tutti i front-end, tutti i back-end, tutte le patch del database) o qualsiasi cifra umanamente ragionevole. Dopo averli consolidati, utilizzare fetche lavorare il rebase sul ramo upstream. Questo non ti salverà dai conflitti a meno che il tuo team non riveda il proprio approccio, ma renderà la tua vita meno dolorosa.

Se hai ulteriori domande sulle attività specifiche, sentiti libero di cercare e chiedere su Stackoverflow.

[Modifica] sulla regola no-reformat e boy scout. Ho leggermente riformulato il formato RE per evidenziare che quello che intendo è il compito di formattare da zero l'intero file sorgente, incluso il codice che non è stato toccato da te. Al contrario di formattare sempre il proprio codice, che è perfettamente boy-scouty, un certo numero di sviluppatori, incluso me stesso, viene utilizzato per riformattare l'intero file con le capacità dell'IDE. Quando il file viene toccato da altri, anche se le righe interessate non vengono modificate nel loro contenuto e semantica, Git lo vedrà come un conflitto. Solo un editor molto sensibile al linguaggio può suggerire che il conflitto è legato solo alla formattazione e all'unione automatica del frammento meglio formattato. Ma non ho prove di alcuno di questi strumenti.

Dopotutto, la regola del boy scout non ti obbliga a pulire il casino degli altri. Solo tua.

Innanzitutto, non pensare di scartare le modifiche. Perderai l'opportunità di imparare il processo di unione.

In secondo luogo, trova una persona che ha lavorato ai file che causano conflitti. Puoi vedere la storia. Parla con la persona e risolvi i conflitti in quei file. Fai lo stesso per altri conflitti.

Se ci sono troppi conflitti, il tuo compito potrebbe essere minore, ma ripetitivo. Prova a trovare uno schema. Ciò aiuterebbe a risolvere i conflitti con gli strumenti client dell'interfaccia utente di Git. Uso TortoiseGit. Aiuta a unire.

E per evitare in futuro,

• È una buona pratica unire regolarmente il ramo di sviluppo al ramo di funzionalità.

• Se hai abilitato CI, vedi se lo strumento CI fornisce una generazione di diramazioni. Questo dovrebbe basarsi su ogni controllo effettuato nel ramo della funzionalità, ma dopo la fusione si sviluppa il ramo.

Dovresti eseguire regolarmente (quotidianamente) il comando 'git fetch' (non git pull) dal tuo ramo di sviluppo. Ciò consentirà ad altre persone di apportare modifiche e le introdurrà nel ramo delle funzionalità senza tentare di integrare le modifiche nel ramo.

Questo è qualcosa di cui dovresti parlare con lo sviluppatore principale (non necessariamente il tuo manager), perché la tua azienda potrebbe avere i propri standard o modi consigliati di gestire questo problema; è molto comune. Non aspettare fino alla prossima settimana: scopri subito il processo e chiedi se puoi impegnarti in qualche banale lavoro (come la formattazione del codice o l'aggiunta di commenti) in modo da poter testare il processo.

Ovviamente la prima cosa è evitare che più persone lavorino sugli stessi file in primo luogo, almeno in un modo che porti a conflitti difficili. L'aggiunta di elementi nelle enumerazioni non è un problema, purché venga utilizzato un buon formato di codice. Modificare il flusso di controllo in diversi modi e spostare il codice è molto più complicato. A volte questo è inevitabile comunque. Dovrai porre domande quando risolvi conflitti veramente complessi.

Detto questo, vedo molte risposte che raccomandano di fondersi / rifarsi per svilupparsi regolarmente. Sarei molto meno entusiasta di questo tipo di consigli. Il tuo obiettivo a questo punto è rendere il processo di risoluzione dei conflitti il ​​più semplice e sicuro possibile. Una cosa che aiuterà enormemente in questo processo è avere immediatamente disponibili tutti i test di regressione, inclusi quelli nuovi che fanno parte della tua nuova funzionalità. Se sincronizzi il tuo ramo molto regolarmente con lo sviluppo, invariabilmente finirai per dover risolvere i conflitti mentre hai quasi finito di implementare effettivamente la tua funzione. Ciò significa che sarà molto più difficile cercare di capire cosa dovrebbe fare il codice, dato che non lo hai fatto. Prima di tentare di unire, assicurati che il tuo ramo sia un'unità coerente di cambiamento. Anche meglio,

Ho cercato di non andare nel merito del rebase sull'unione che è probabilmente per un'altra domanda. In questo contesto gli strumenti non contano davvero.

Quando sono pronto a ricollegare il mio ramo allo sviluppo, gli altri hanno apportato così tanti cambiamenti che la risoluzione dei conflitti è schiacciante

Sembra uno scenario ideale per la programmazione di coppie !

Maggiori informazioni sui vantaggi e sugli approcci di base:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Naturalmente accelererai nel tempo lavorando da solo, ma può essere scoraggiante fino a quel momento, e talvolta è anche un lungo raggio. Inoltre, mentre le persone possono imparare rapidamente a trovarsi in un ambiente stressante sempre sotto pressione per recuperare il ritardo, altri che non imparano bene sotto costante pressione saranno ostacolati.

Invece di lavorare su un ramo da solo e cercare di tenere il passo con altri sviluppatori che sono ovviamente molto più veloci di te, lavoreresti invece direttamente (stesso PC) con un altro sviluppatore. In questo modo ricevi consigli immediati e probabilmente raccoglierai consigli su come accelerare ecc.

Avresti trovato l'approccio migliore per il particolare codice nel tuo progetto, poiché la programmazione in coppia non ha sempre senso per alcuni progetti, anche se probabilmente ha sempre senso imparare anche se ti siedi e guardi qualcuno più esperto di te (fintanto che sono un buon sviluppatore, l'esperienza non significa necessariamente che usano buone pratiche).

Sedersi con uno sviluppatore più veloce ed esperto ha il potenziale per aiutare:

• Ridurrà probabilmente i conflitti di fusione poiché lavorare con qualcuno più esperto aumenterà i tempi di completamento rispetto al tuo lavoro da solo
• Poiché ti insegneranno è probabile che saranno più lenti di quanto non lavorerebbero da soli, quindi potrebbero esserci ancora dei conflitti di unione e quindi possono risolverli con qualcuno esperto e quindi forse prendere qualche consiglio su come risparmiare tempo, ecc.
• Aiutarti a vedere potenziali trucchi e modi per essere più veloce (anche se essere lenti a volte è semplicemente una mancanza di esperienza piuttosto che una mancanza di buone pratiche)
• Può porre immediatamente domande quando qualcosa non ha senso o non è chiara al 100%
• Lavorare 1: 1 è utile per l'apprendimento perché la persona a cui vorresti chiedere aiuto capisce già il codice esatto e lo scenario mentre ci stanno lavorando, senza una programmazione di coppia devi spiegare il codice e lo scenario, che spesso finisce con un problema e quindi perdi il loro tempo / attenzione nel ricevere effettivamente i consigli necessari
• Conosci il processo mentale di qualcuno più esperto e stagionato e con buone comunicazioni imparerai sicuramente cose nuove

Esiste una tattica che posso usare oltre a "essere più bravo a programmare"? Ho intenzione di parlarne con il mio supervisore la prossima settimana.

Il mio consiglio è di discutere la programmazione di coppia con gli altri sviluppatori e quindi di rivolgersi al proprio supervisore. Se sono decenti apprezzeranno la tua iniziativa che ha più possibilità per te di presentare i pro della programmazione in coppia (se ne hanno bisogno, la maggior parte delle persone lo sa ed è risaputo perché aiuta).

Ci sono alcuni problemi di base qui. Molto probabilmente i tuoi problemi di fusione non sono colpa tua e sono più comunemente un sintomo di cattive pratiche.

1) Idealmente dovresti fondere il tuo ramo per sviluppare ogni giorno. Cerca di avere un codice funzionante almeno una volta al giorno che superi tutti i test in modo da poter unirti allo sviluppo.

2) Se non hai un codice di lavoro in qualsiasi momento durante la tua solita giornata lavorativa, probabilmente hai blocchi di codice troppo grandi su cui lavorare. È necessario suddividere l'attività in attività più piccole che possono essere completate (idealmente indipendentemente l'una dall'altra) più rapidamente in modo da poterle unire.

3) I file dei tuoi progetti sono probabilmente troppo grandi. Se ci sono molti conflitti di unione per un file, ci sono troppe persone che lavorano su un file. Idealmente qualcosa su cui una persona sta lavorando dovrebbe essere separata da ciò su cui stanno lavorando tutti gli altri.

4) La tua squadra potrebbe essere troppo grande. Se trovi più facile buttare via un'intera funzionalità e ricominciare, è probabile che ci siano troppe persone che commettono codice nello stesso repository.

5) Potresti non avere standard di formattazione del codice coerenti. Se non tutti usi costantemente la stessa formattazione del codice, otterrai molti conflitti diversi per lo stesso codice. A seconda di come è impostato il tuo git, questi potrebbero anche dipendere da conflitti di spazi bianchi (terminazioni di riga, rientri, tabulazioni vs spazi).

6) Le persone potrebbero spingere i loro cambiamenti direttamente nel ramo di sviluppo.

Ecco cosa si può fare: 1) Se non è possibile unire in sviluppare ogni giorno, unire / rebase svilupparsi in vostra filiale ogni giorno (o più spesso).
2) Cerca di separare il tuo codice dal codice di ogni altro.
3) Parla con il resto del team su funzioni più piccole, standard di codifica coerenti e una migliore organizzazione del codice (file più piccoli, funzioni più piccole).

In realtà sembra più facile scartare il mio lavoro e ricominciare il compito, che ovviamente non è una soluzione sostenibile)

Il più delle volte, questo è quello che faccio, la prima volta che risolvo un bug o apporto una modifica al sistema, sto imparando come farlo. La prossima volta che risolverò lo stesso bug, ci vorrà solo l'1% delle volte poiché ora capisco il problema.

Trovo anche che quando rifaccio un po 'di lavoro, scrivo un codice migliore .....

Quindi non c'è nulla di sbagliato nel creare un nuovo ramo dal master, rifare il tuo lavoro al suo interno, mentre usi il tuo "ramo privato" per ricordarti cosa devi fare.

È anche possibile che tu abbia scoperto un modo per dividere la modifica in parti logiche e corrette, ognuna che viene unita nel ramo master una volta completata. Ad esempio, i test unitari e le modifiche al codice back-end possono essere eseguiti e uniti. Quindi, in un'operazione separata, è possibile apportare le modifiche all'interfaccia utente che li utilizzano, quindi avere meno rischi di qualcun altro che modifica lo stesso file UI.

Se non si desidera unire il ramo di sviluppo nel ramo troppo spesso, è possibile ottenere un flusso di lavoro più simile a svn utilizzando git pull --rebase. Questo attirerà i nuovi commit e rinnoverà i tuoi commit su di essi. Ciò significa che quando unisci il tuo ramo allo sviluppo, sarà una fusione in avanti veloce (come se avessi aggiunto tutti i tuoi impegni passati contemporaneamente uno dopo l'altro) e non avresti alcun conflitto di unione, perché li hai risolti tutti durante git pull --rebase.

Ma più impegni prendi prima di fondere il tuo ramo in sviluppo o sviluppo nel tuo ramo, più complicato otterrà il successivo rebase e sovverte un po 'il senso dei rami delle caratteristiche, poiché il tuo ramo esiste solo finché non è unito .

Quando lavori in file comuni, in entrambi i casi tu o i tuoi compagni di squadra dovete risolvere tutti i conflitti prima che l'unione finisca, quindi in primo luogo, per favore , non essere sconvolto . Stai ancora facendo il lavoro di progetto ed essere orgoglioso del tuo lavoro. Ora per fare una mossa più intelligente, puoi seguire alcuni suggerimenti di seguito.

1. Dividi i compiti in modo indipendente:

   Prima di iniziare il lavoro, pianificare e dividere interi compiti in modo tale che l'attività assegnata a ciascun membro del team sia il più indipendente e modulare possibile (per evitare potenziali conflitti durante lo sviluppo). Puoi avvicinarti al tuo scrum leader per assegnare alcune attività indipendenti per te mentre sei un principiante.

2. Unisci commit frequenti granulari:

   Non attendere il completamento dell'attività completa prima della modifica finale. Ovviamente qualsiasi attività più grande può essere suddivisa in più sottoattività. Pertanto, un approccio migliore consiste nell'unire frequentemente piccoli commit per attività secondarie più piccole allo scopo di evitare ingombranti risoluzioni dei conflitti.

3. Rebase il tuo ramo frequentemente:

   Fai una pratica di rebase frequente alla tua filiale locale con una remota. Puoi utilizzare il comando seguente per rifare frequentemente il tuo ramo locale con uno remoto,

   git pull --rebase #or
   git pull --rebase origin dev #when dev is remote branch
   

   Questo è finora il comando git più utile per me nella mia vita di sviluppo.

4. Lavora a stretto contatto con i compagni di squadra:

   Se hai davvero bisogno di lavorare in parallelo con il tuo compagno di squadra in un compito comune, ti preghiamo di collaborare. Può aspettare qualche volta per evitare la complessa risoluzione dei conflitti per la tua convenienza poiché sei un principiante ed è un'esperta.

5. Essere abituati con le opzioni git:

   Usa il potere degli strumenti di fusione git. Esistono molti modi convenienti per risolvere i conflitti durante l'unione. L'unione delle strategie a volte potrebbe essere di grande aiuto. Essere abituati e senza paura con i comandi git.