6 Git errori che farai e come risolverli

Una delle ragioni principali per cui gli sviluppatori utilizzano un sistema di controllo del codice sorgente come Git è per evitare disastri. Se fai qualcosa di semplice come eliminare per errore un file, o scopri che le modifiche che hai fatto a una dozzina di file sono state tutte sconsiderate, puoi annullare ciò che hai fatto con poca fatica.

Alcuni errori di Git sono più intimidatori e difficili da invertire, anche per gli utenti esperti di Git. Ma con un po 'di attenzione, e a patto di non farti prendere dal panico, puoi tornare indietro da alcuni dei peggiori disastri di Git noti ai programmatori.

Ecco un elenco di molti dei più grandi fischi di Git, insieme a suggerimenti per tirarsi indietro e prevenirne alcuni. Più si scende nell'elenco, più grandi saranno i disastri.

Errore Git n. 1: hai dimenticato di aggiungere modifiche all'ultimo commit

Questo è uno degli errori Git più facili da cui recuperare. Supponiamo che tu abbia affidato del lavoro a una filiale locale, poi ti sia reso conto di non aver messo in scena un numero di file necessari. O hai dimenticato di aggiungere alcuni dettagli nel messaggio di commit.

Niente paura. Per prima cosa, se devi mettere in scena nuove modifiche, fallo. Quindi digita git commit --amendper modificare il messaggio di commit. Una volta che hai finito, premi Esc, quindi digita :xqper salvare e uscire dall'editor. (Quest'ultimo passaggio è quello che spesso turba i nuovi arrivati ​​di Git, che non sempre si rendono conto che l'editor di Git integrato è proprio un animale a sé stante.)

Se stai solo modificando i file e non è necessario modificare il messaggio di commit, puoi utilizzare git commit --amend --no-editper aggiungere i file e saltare il processo di modifica del messaggio.

Un modo per evitare questo tipo di errore è modificare il modo in cui effettui i commit in Git. Se stai lavorando su qualcosa in cui effettui costantemente piccoli impegni per tenere traccia delle revisioni incrementali, eseguili in un ramo usa e getta. Mentre lo fai, documenta le principali modifiche che stai apportando da qualche parte: non aspettare di dover affrontare la git commitriga di comando per scrivere tutto. Quindi, quando raggiungi un traguardo importante, usa git merge --squashdal tuo ramo usa e getta per salvare i risultati nel ramo work-in-progress come un singolo commit pulito e usa le note che hai preso per il messaggio di commit.

Errore Git n. 2: hai eseguito il commit delle modifiche al master (locale)

Un altro errore comune: hai diligentemente commesso una serie di modifiche ... ma per errore al ramo principale del tuo repository. Quello che volevi veramente fare era impegnarli in un nuovo ramo, o in quel devramo che hai specificamente per rompere le modifiche.

Non è tutto perduto. Questo errore può essere risolto in tre comandi:

git branch new-branch

git reset HEAD ~ --hard

git checkout new-branch

Il primo comando crea il nuovo ramo con cui vogliamo lavorare. Il secondo comando ripristina il ramo principale appena prima dell'ultimo commit, ma lascia le modifiche appena apportate nel nuovo ramo. Infine, passiamo al nuovo ramo dove ti aspettano le tue modifiche.

Se hai eseguito più commit, usa git reset HEAD~ --hard, dov'è il numero di commit a cui vuoi tornare. Oppure puoi usare git reset , dov'è l'ID hash del commit di destinazione se lo hai a portata di mano.

Per evitare questo errore, prendi l'abitudine di creare nuovi rami e passare a loro, anche se verranno semplicemente scartati, ogni volta che inizi una sessione con il tuo codice.

Errore di Git n. 3: hai spostato un file o una directory nel cestino

Un altro disastro comune è erroneamente cestinare il contenuto di un file ... e scoprirlo molti si impegnano nel ramo solo dopo il fatto. Fortunatamente c'è una soluzione facile.

Innanzitutto, usa git logo gli strumenti Git incorporati nell'IDE per trovare l'ID hash per un commit precedente alla modifica del file. Successivamente, utilizzare git checkout hash_id -- /path/to/fileper estrarre solo quel file dal commit in questione. Notare che il percorso dovrebbe essere relativo alla radice del progetto. In questo modo la versione precedente del file verrà posizionata nell'area di gestione temporanea del progetto.

Se vuoi semplicemente tornare indietro n commit, non hai bisogno dell'ID hash. Puoi semplicemente emettere il comando git checkout HEAD~ -- /path/to/file, dov'è il numero di commit a cui vuoi tornare.

Se vuoi controllare un'intera directory di file, usa il formato jolly di Git per i percorsi dei file. Ad esempio, l'inserimento  git checkout HEAD~1 -- ./src/**ti riporterà indietro di un commit e ripristinerà tutto nella /srcdirectory dalla radice del tuo progetto.

Errore Git n. 4: hai cancellato accidentalmente un ramo

Ecco uno scenario che tutti temiamo: eliminare accidentalmente un intero ramo dal nostro repository. Questo può essere molto facile da recuperare o un po 'più complicato, a seconda delle circostanze.

Per prima cosa, usa git reflogper trovare l'ultimo commit fatto al ramo. Quindi usa l'ID hash per creare un nuovo ramo:

git checkout -b restored-branch

Nota che questo scioglierà la tua pancetta solo se il ramo in questione è già stato unito. Se elimini forzatamente un ramo non unito , hai un altro modo per trovarlo, a condizione che non sia stato eseguito git gcsul repository:

git fsck --full --no-reflogs --unreachable --lost-found

Questo scaricherà un elenco di tutti gli hash di commit per gli oggetti che non sono più raggiungibili, inclusi i rami eliminati. Cerca una voce "commit irraggiungibile" dal fondo dell'elenco verso l'alto e prova a ripristinare quell'ID hash in un nuovo ramo per vedere se è quello che hai eliminato. In caso contrario, risali l'elenco fino a quello successivo e vedi cosa puoi recuperare.

Come regola generale, non forzare mai l'eliminazione di un ramo per impostazione predefinita, poiché potresti facilmente finire per gettare rifiuti su un ramo non unito che ha ancora qualcosa di prezioso in esso. Se abitualmente elimini forzatamente i rami, questo è un segno che le tue abitudini lavorative con i rami devono essere meno disordinate.

Errore di Git # 5: hai distrutto il ramo remoto con git push

Una volta stavo lavorando su una copia locale di un repository GitHub e ho erroneamente inviato il mio ramo master alla copia remota con l' --forceopzione. Mi sono ritrovato con una copia pubblica di un repo che non era in uno stato utilizzabile in quel momento. Grandi oops.

Se hai commesso un errore come questo e il tuo repository è stato sincronizzato con il repository remoto abbastanza di recente, puoi utilizzare la tua copia del ramo del repository remoto per risolverlo. Passa al ramo che devi risincronizzare, supponendo che tu non sia già lì, ed esegui questo comando:

git reset --hard /@{1}

Ciò ripristinerà la tua copia di all'ultima versione sincronizzata di . Nel mio caso il ramo era mastere il repository remoto lo era origin, quindi avrei potuto usare git reset --hard origin/[email protected]{1}.

Quindi utilizzare git push -f per ripristinare il repository remoto allo stato precedente.

Un modo per evitare che ciò accada di nuovo è impedire la spinta forzata. Puoi configurarlo sul repository Git remoto con questo comando:

git config --system receive.denyNonFastForwards true

Potrebbe arrivare un momento in cui è necessario eseguire una spinta forzata, ma probabilmente è meglio attivarlo quando ne hai bisogno e disattivarlo quando non lo fai.

Errore di Git n. 6: hai inviato informazioni private a un repository pubblico

Questo potrebbe essere il problema di Git peggiore e più difficile da affrontare. Hai commesso per errore dati sensibili in un repository pubblico e desideri asportare chirurgicamente i file dal repository. Devi assicurarti che i dati sensibili non possano essere trovati anche tornando a un commit precedente, ma devi farlo  senza toccare nient'altro.

Ciò è doppiamente difficile se il fascicolo in questione è stato archiviato, oh, sei settimane fa, e nel frattempo è stato eseguito un carico di altri lavori importanti. Non puoi semplicemente tornare a prima che il file fosse aggiunto; distruggerai tutto il resto nel processo.

La buona notizia: alcuni intrepidi esperti di Git hanno creato uno strumento, BFG Repo-Cleaner, specificamente allo scopo di rimuovere i dati non validi dai repository Git. BFG Repo-Cleaner ti consente di eseguire rapidamente attività comuni su un repository come rimuovere tutti i file che corrispondono a un particolare carattere jolly o che contengono determinati testi. Puoi persino passare un file che elenca tutti i testi indesiderati.

BFG Repo-Cleaner è essenzialmente automazione per un processo in più fasi che utilizza git filter-branch. Se preferisci fare le cose a mano, GitHub ha una procedura dettagliata del processo. Ma lo strumento BFG copre la stragrande maggioranza dei casi d'uso comuni, molti dei quali sono integrati nelle opzioni della riga di comando dello strumento. Inoltre, il processo è lungo e complesso ed è fin troppo facile spararti ai piedi da qualche parte lungo la strada se lo fai a mano.

Nota che se pulisci i dati da un ramo locale che deve essere sincronizzato altrove, non sarai in grado di sincronizzare se non tramite un push forzato ai rami remoti. L'intero albero del commit deve essere riscritto, quindi in sostanza stai scrivendo una cronologia completamente nuova in remoto. Dovrai anche assicurarti che tutti gli altri tirino una nuova copia del repository riscritto dopo le modifiche, perché anche i loro repository non saranno più validi.