Git pull override all

di Piotr Gaczkowski

Quando impari a programmare, prima o poi imparerai anche a conoscere i sistemi di controllo di versione. E mentre ci sono molti strumenti concorrenti in questo spazio, uno di questi è lo standard de facto utilizzato da quasi tutti nel settore. È così popolare che ci sono aziende che usano il suo nome nel loro marchio. Stiamo parlando di Git, ovviamente.

Sebbene Git sia uno strumento potente, il suo potere è ben nascosto. Ci sono alcuni concetti essenziali che devi comprendere per diventare davvero abile con Git. La buona notizia è che una volta imparati, difficilmente ti imbatterai in guai da cui non puoi scappare.

In un tipico flusso di lavoro Git si userà un repository locale, un repository remoto e uno o più rami. I repository memorizzano tutte le informazioni sul progetto, inclusa la sua intera storia e tutti i rami. Un ramo è fondamentalmente un insieme di modifiche Passando da un progetto vuoto allo stato corrente.

Dopo aver clonato un repository, si lavora sulla copia locale e si introducono nuove modifiche. Fino a quando non si esegue il push delle modifiche locali nel repository remoto, tutto il lavoro è disponibile solo nel computer.

Al termine di un'attività, è il momento di sincronizzarsi con il repository remoto. Si desidera eseguire il pull delle modifiche remote per tenere il passo con l'avanzamento del progetto e si desidera eseguire il push delle modifiche locali per condividere il lavoro con altri utenti.

Tutto va bene quando tu e il resto del tuo team lavorate su file completamente separati. Qualunque cosa accada, non vi calpesterete i piedi a vicenda.

Tuttavia, ci sono momenti in cui tu e i tuoi compagni di squadra introducete contemporaneamente modifiche nello stesso posto. Ed è qui che di solito iniziano i problemi.

Hai mai eseguito solo per vedere il temuto ? Prima o poi, tutti si imbattono in questo problema.

Ciò che è più confuso qui è che Non vuoi unire nulla, basta tirare, giusto? In realtà, tirare è un po' più complicato di quanto si possa pensare.

Il pull non è una singola operazione. Consiste nel recuperare i dati dal server remoto e quindi unire le modifiche con il repository locale. Queste due operazioni possono essere eseguite manualmente se lo si desidera:

La parte significa che:

• Git unirà le modifiche dal repository remoto denominato (quello da cui hai clonato)
• che sono state aggiunte al
• che non sono già presenti nel tuo ramo locale estratto

Poiché Git esegue le fusioni solo quando non ci sono modifiche di cui non è stato eseguito il commit, Ogni volta che si esegue con modifiche non confermate potrebbe metterti nei guai. Fortunatamente, ci sono modi per tirarsi fuori dai guai tutti interi!

_Photo da [Unsplash](https://unsplash.com/@sneakyelbow?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Sneaky Elbow / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm campaign=api-credit)

Quando hai modifiche locali non impegnate e vuoi comunque estrarre una nuova versione dal server remoto, il tuo caso d'uso rientra tipicamente in uno dei seguenti scenari. O:

• non ti interessano le modifiche locali e vuoi sovrascriverle,
• ti interessano molto le modifiche e vorresti applicarle dopo le modifiche remote,
• vuoi scaricare le modifiche remote ma non applicarle ancora

Ciascuno degli approcci richiede una soluzione diversa.

Non ti interessano le modifiche

locali In questo caso, si desidera semplicemente eliminare tutte le modifiche locali di cui non è stato eseguito il commit. Forse hai modificato un file per sperimentare, ma non hai più bisogno della modifica. Tutto ciò che ti interessa è essere aggiornato con l'upstream.

Ciò significa che ne aggiungi un altro Passaggio tra il recupero delle modifiche remote e l'unione. Questo passaggio ripristinerà il ramo al suo stato non modificato, consentendo così di funzionare.

Se non vuoi digitare il nome del ramo ogni volta che esegui questo comando, Git ha una bella scorciatoia che punta al ramo upstream: . Un ramo upstream è il ramo nel repository remoto in cui si esegue il push e il recupero.

Ecco come apparirebbero i comandi di cui sopra con la scorciatoia:

Stiamo citando la scorciatoia nell'esempio per evitare che la shell la interpreti.

Ti preoccupi molto delle modifiche locali

Quando le tue modifiche non salvate sono significative per te, ci sono due opzioni. Puoi impegnarli e poi eseguirli, oppure puoi metterli da parte.

Mettere da parte le modifiche significa mettere via le modifiche per un momento per riportarle in un secondo momento. Per essere più precisi, crea un commit che non è visibile sul tuo ramo corrente, ma è comunque accessibile da Git.

Per ripristinare le modifiche salvate nell'ultima scorta, utilizzare il comando. Dopo aver applicato correttamente le modifiche nascoste, questo comando rimuove anche il commit di archiviazione poiché non è più necessario.

Il flusso di lavoro potrebbe quindi essere simile al seguente:

Per impostazione predefinita, le modifiche dalla scorta diventeranno in scena. Se si desidera rimuoverli dalla fase, utilizzare il comando (se si utilizza Git più recente di 2.25.0).

Vuoi solo scaricare le modifiche remote

L'ultimo scenario è leggermente diverso dai precedenti. Diciamo che ti trovi nel bel mezzo di un refactoring molto disordinato. Né perdere le modifiche né metterle da parte è un'opzione. Tuttavia, si desidera comunque avere le modifiche remote disponibili per l'esecuzione su di esse.

Come probabilmente avrete capito, scaricare le modifiche remote non richiede affatto! è appena sufficiente.

Una cosa da notare è che, per impostazione predefinita, vi porterà solo le modifiche dal ramo corrente. Per ottenere tutto le modifiche da tutti i rami, utilizzare . E se desideri ripulire alcuni dei rami che non esistono più nel repository remoto, lo farai tu!

_Photo da [Unsplash](https://unsplash.com/@lenin33?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Lenin Estrada / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm campaign=api-credit)

Hai sentito parlare di Git Config? Si tratta di un file in cui Git memorizza tutte le impostazioni configurate dall'utente. Risiede nella tua home directory: come o . Puoi modificarlo per aggiungere alcuni alias personalizzati che saranno intesi come comandi Git.

Ad esempio, per avere una scorciatoia equivalente a (che mostra la differenza tra il ramo corrente e i file di staging), è necessario aggiungere la seguente sezione:

Dopodiché, è possibile eseguire ogni volta che si desidera rivedere le modifiche. Andando in questo modo, possiamo impostare alcuni alias relativi ai casi d'uso precedenti.

In questo modo, l'esecuzione sovrascriverà le modifiche locali, mentre le conserverà.

Le menti curiose potrebbero aver già scoperto che esiste una cosa come . Tuttavia, questa è una bestia molto diversa da quella presentata in questo articolo.

Potrebbe sembrare qualcosa che ci aiuterebbe a sovrascrivere le modifiche locali. Invece, ci consente di recuperare le modifiche da un ramo remoto a un ramo locale diverso. modifica solo il comportamento della parte di recupero. È quindi equivalente a .

Come , ci permette di specificare su quale ramo locale e remoto vogliamo operare. significherà che le modifiche nel ramo dal repository remoto finiranno per essere visibili sul ramo locale . Quando un'operazione di questo tipo modifica la cronologia esistente, non è consentita da Git senza un parametro esplicito.

Proprio come consente la sovrascrittura dei rami remoti, (o ) consente la sovrascrittura dei rami locali. Lo è Utilizzato sempre con i rami di origine e di destinazione menzionati come parametri. Un approccio alternativo alla sovrascrittura delle modifiche locali utilizzando .

Il mondo di Git è vasto. Questo articolo ha trattato solo uno degli aspetti della manutenzione del repository: incorporare le modifiche remote in un repository locale. Anche questo scenario quotidiano ci ha richiesto di esaminare in modo leggermente più approfondito i meccanismi interni di questo strumento di controllo della versione.

Imparare i casi d'uso reali ti aiuta a capire meglio come funziona Git sotto il cofano. Questo, a sua volta, ti farà sentire forte ogni volta che ti metti nei guai. Lo facciamo tutti di tanto in tanto.