Domande frequenti su Git

Assicurarsi prima di tutto di avere configurato un origin repository. Se il repository è stato clonato usando git clone. Quando si estrae un ramo che non esiste in locale, Git verifica se è presente un ramo remoto con lo stesso nome. In caso affermativo, Git crea un ramo locale che fa riferimento al ramo remoto. Usare git pull per scaricare i commit e aggiornare la cronologia dei rami in locale.

Eseguire git branch senza argomenti per visualizzare i rami locali ed evidenziare quello estratto. In Visual Studio la barra di stato visualizza anche il ramo corrente quando si usa un progetto archiviato in un repository Git locale.

È consigliabile eseguire commit separati per modifiche logiche distinte. Si pensi ai commit come voci in un logbook. Ogni volta che si apporta una modifica che vale la pena notare, registrarla in un commit. Un approccio comune consiste nel consentire commit locali frequenti, ma schiacciarli tramite ribasing prima di eseguire il push. Ciò garantisce flessibilità mantenendo semplificata la cronologia dei commit.

I progetti di grandi dimensioni con molti commit e collaboratori possono comportare una main cronologia dei rami che riflette lo sviluppo di rami di argomento più del progetto complessivo. Git consente di condensare i commit nei rami tramite commit di squash e ribasing. Il commit di squash rende la cronologia dei rami meno dettagliata, semplificando la cronologia dei commit nel ramo main dopo l'unione.

Usare il git blame comando per scoprire chi ha apportato una particolare modifica a un file. Dal repository locale è possibile eseguire git blame con il -L parametro , specificando le righe di interesse. Blame produce un output formattato che mostra il commit che ha aggiornato la riga e il nome della persona che ha eseguito il commit.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame cerca automaticamente la cronologia dei commit. È anche possibile esaminare la cronologia di un file nel portale Web per determinare chi ha apportato una modifica e quando. Aprire Esplora codice per il repository e il ramo, quindi selezionare il file di interesse. Azure Repos mostra una cronologia di commit completa per il file nel ramo corrente.

L'estrazione in un ramo diverso in Git influisce sullo stato dei file nel file system. Git usa la cronologia dei commit per assicurarsi di usare i file che rappresentano lo stato del ramo. Se si tenta di modificare i rami mentre si dispone di modifiche di cui non è stato eseguito il commit, tali modifiche verranno sovrascritte durante il checkout. Poiché Git non vuole perdere accidentalmente le modifiche, impedisce l'esecuzione del checkout. È possibile procedere in due modi:

• Abbandonare le modifiche e tornare al commit più recente. Vedere Annullamento delle modifiche in Git per istruzioni su come eseguire il rollback al commit più recente.
• Esegui il commit delle modifiche. Vedere Salvataggio del lavoro in Git con commit.
• Stashing del lavoro corrente, salvando le modifiche per un secondo momento e pulendo l'area di lavoro fino all'ultimo commit.

Questo problema è correlato ai conflitti di unione in file binari di grandi dimensioni. Il limite corrente per i file è 100 MB. La soluzione alternativa consiste nel risolvere i conflitti di merge in locale unendo la destinazione all'origine in locale, risolvendo i conflitti ed eseguendo il push delle modifiche.

Git LFS (Archiviazione file di grandi dimensioni) è consigliato per l'archiviazione di file binari di grandi dimensioni, non solo per evitare conflitti, ma anche per gestire le dimensioni complessive del repository, che influiscono sui tempi di clonazione e push.

Se si desidera salvare le modifiche senza eseguirne il commit, usare Git stash. Stash salva le modifiche correnti di staging e non preparate nel ramo e ripristina lo stato dell'ultimo commit. È quindi possibile passare a un altro ramo, eseguire il lavoro e successivamente eseguire stash apply per ripristinare le modifiche.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

Quando si esegue [git stash apply], le modifiche non aggiornate più recenti vengono applicate al ramo corrente. Se si verifica un conflitto, [stash] ripristina le modifiche per i file che non sono in conflitto e crea marcatori di conflitto nei file che eseguono. In questo caso, è consigliabile unire manualmente le modifiche.

Dopo aver finito con lo stash, eliminarlo con [git stash drop]. Questo comando rimuove l'ultimo set di modifiche non allineate.

È possibile avere più stashe, ma la gestione richiede una manipolazione più manuale perché è necessario applicare e eliminare in modo esplicito gli stashe. Per altre informazioni, vedere la documentazione di Git Stash.

Per impostazione predefinita, Git della riga di comando usa un editor della riga di comando per richiedere messaggi di commit, eseguire rebase e altre operazioni che richiedono informazioni aggiuntive per il completamento. L'editor predefinito è configurato usando git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Git per Windows semplifica l'impostazione del Blocco note come editor:

> git config core.editor notepad

Questo comando configura Il Blocco note di Windows per modificare le informazioni Git in base alle esigenze e passare correttamente il testo da Git al Blocco note. È anche possibile specificare

> git config format.commitMessageColumns 72 

Per mantenere le colonne di testo nei messaggi di commit nella posizione 72 preferita e il ritorno a capo automatico dopo aver raggiunto tale limite di caratteri su una riga.

Git inserisce informazioni su nome utente e indirizzo di posta elettronica all'interno di ogni commit e Azure Repos usa queste informazioni quando si visualizzano i commit e quando si usano le richieste pull. Se si lavora alla riga di comando, è possibile aggiornare il nome e le informazioni di posta elettronica visualizzate usando il git config comando :

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

L'opzione --global imposta il messaggio di posta elettronica e il nome inclusi nei commit per tutti i repository Git in questo sistema. Se si vogliono modificare le impostazioni per un singolo repository, è necessario passare alla directory in cui si trova il repository Git ed eseguire i comandi precedenti senza il --global flag .

È anche possibile modificare il nome e le impostazioni di posta elettronica da Visual Studio. Dal menu Git selezionare Impostazioni nella finestra di dialogo Opzioni, selezionare Impostazioni globali Git o Impostazioni>repository Git Generale.

Visual Studio 2019 versione 16.8 e versioni successive offre un'esperienza di controllo della versione Git mantenendo al tempo stesso l'interfaccia utente git di Team Explorer . Per usare Team Explorer, deselezionare Strumenti>Opzioni>anteprima Funzionalità>Nuova esperienza utente Git dalla barra dei menu. È possibile eseguire l'esercizio delle funzionalità Git da entrambe le interfacce in modo intercambiabile.

In Team Explorer scegliere Impostazioni e in Git selezionare il collegamento Impostazioni globali o Impostazioni repository.