Domande frequenti su Git

Prima di tutto, assicurarsi di avere configurato un origin repository. Se il repository è stato clonato con git clone, ne è già disponibile uno. Quando si estrae un ramo che non esiste in locale, Git determina se esiste un ramo remoto con lo stesso nome. In tal caso, 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 il ramo corrente quando si usa un progetto archiviato in un repository Git locale.

Apportare commit separati per modifiche logiche distinte. Si pensi ai commit come voci in un registro. 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 comprimerli tramite rebasing prima di eseguire il push. Questo approccio offre flessibilità mantenendo la cronologia dei commit semplificata.

Nei progetti di grandi dimensioni con molti commit e collaboratori, la cronologia del ramo può riflettere lo sviluppo di rami tematici main più che l'avanzamento complessivo del progetto. È possibile condensare i commit nei rami tramite squash dei commit e rebase. L'utilizzo dello squashing dei commit semplifica la cronologia dei rami, il che rende più pulita la cronologia dei commit nel ramo principale dopo la fusione.

Usare il git blame comando per scoprire chi ha apportato una particolare modifica a un file. Esegui git blame dal repository locale con il parametro -L per specificare le righe di interesse. Blame produce un output formattato che mostra il commit che ha aggiornato la riga e il nome di chi 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. Apri Esplora codice per il tuo repository e ramo, quindi seleziona il file di interesse. Azure Repos mostra una cronologia di commit completa per il file nel ramo corrente.

Il comando checkout di un branch diverso in Git influisce sullo stato dei file sul tuo file system. Git utilizza la cronologia dei commit per garantire l'utilizzo di 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 vengono sovrascritte durante il checkout. Per evitare la perdita accidentale di modifiche, Git blocca il checkout. Sono disponibili queste opzioni:

• 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.
• Conferma le 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 si verifica a causa di conflitti di unione in file binari di grandi dimensioni. Il limite di dimensioni del file corrente è 100 MB. Per risolvere questo problema, eseguire il merge della destinazione nell'origine localmente, risolvere i conflitti e pushare le modifiche.

Usare Git LFS (Archiviazione file di grandi dimensioni) per file binari di grandi dimensioni per evitare conflitti e gestire le dimensioni complessive del repository, che influiscono sui tempi di clonazione e push.

Per salvare le modifiche senza eseguirne il commit, usare Git stash. Questo comando salva le modifiche preparate e non preparate nel tuo ramo e riporta il ramo allo stato dell'ultimo commit. È quindi possibile passare a un altro ramo, completare 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 esegui git stash apply, le modifiche accumulate più recenti si applicano al ramo corrente. Se si verifica un conflitto, stash ripristina le modifiche per i file che non sono in conflitto e crea indicatori di conflitto nei file in conflitto. Unire manualmente le modifiche in questo caso.

Dopo aver terminato con lo stash, eliminalo con git stash drop. Questo comando rimuove l'ultimo set di modifiche accantonate.

È possibile avere più stashes, ma la gestione richiede più lavoro manuale perché è necessario applicare ed eliminare in modo esplicito ogni stash. Per altre informazioni, vedere la documentazione di Git Stash.

Per impostazione predefinita, Git della riga di comando usa un editor della riga di comando quando richiede messaggi di commit, esegue rebase ed esegue altre operazioni che richiedono informazioni aggiuntive. Configurare l'editor predefinito con 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 tra Git e Blocco note. È anche possibile specificare

> git config format.commitMessageColumns 72 

Questa impostazione mantiene le colonne di testo nei messaggi di commit alla larghezza di 72 caratteri preferita e esegue il wrapping delle righe a tale limite.

Git include un nome utente e un indirizzo di posta elettronica in ogni commit e Azure Repos usa queste informazioni durante la visualizzazione dei commit e l'uso delle richieste pull. Per aggiornare il nome e le informazioni di posta elettronica nella riga di comando, usare 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. Per modificare le impostazioni per un singolo repository, 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. Scegliere Impostazioni dal menu Git. Nella finestra di dialogo Opzioni selezionare Impostazioni globali Git o Impostazioni> repository GitGenerale.

Visual Studio 2019 versione 16.8 e versioni successive offrono 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 usare le funzionalità Git da entrambe le interfacce.

In Team Explorer, scegliere Impostazioni e sotto Git, selezionare il collegamento Impostazioni Globali o Impostazioni del Repository.

Abilitare la traccia dettagliata per ottenere informazioni complete sull'errore. Impostare le variabili di ambiente seguenti prima di eseguire il comando Git:

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

L'output di traccia consente di identificare se l'errore è correlato alla connettività di rete, alla configurazione del proxy, ai certificati SSL o all'autenticazione. Per altre informazioni sulle variabili di ambiente Git, vedere Git Internals - Environment Variables.For more information about Git environment variables, see Git Internals - Environment Variables.

Se si è dietro a un server proxy e Git non è configurato per usarlo, le operazioni di clonazione e push avranno esito negativo con errori 407, 502 o "non è possibile accedere".

Eseguire git config --list per verificare se un proxy è già configurato. In caso contrario, impostare il proxy a livello globale:

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Per configurare un proxy solo per un URL specifico:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Per altre informazioni, vedere la documentazione sulla configurazione di Git.

Se la password è stata modificata o le credenziali memorizzate nella cache non sono aggiornate, le operazioni di clonazione o push di Git falliscono con errori di autenticazione. Reimpostare Git Credential Manager (GCM) per risolvere il problema:

> git config --global --unset credential.helper
> git config --global credential.helper manager

È anche possibile rimuovere le credenziali memorizzate nella cache direttamente in Gestione credenziali di Windows:

1. Aprire Pannello di controllo>Account utente>Gestione credenziali.
2. Selezionare Credenziali di Windows.
3. Trovare e rimuovere voci per git:https://dev.azure.com/<orgname>.

In alternativa, usare la riga di comando:

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

In macOS eseguire git credential reject per cancellare le credenziali archiviate:

echo url=https://dev.azure.com/<orgname> | git credential reject

Dopo aver cancellato le credenziali, ripetere l'operazione di clone o push. Git richiede di ripetere l'autenticazione.

Quando si clona o si esegue il push in un'istanza di Azure DevOps Server che utilizza un certificato autofirmato o emesso da una CA interna, Git genera un errore con:

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

Opzione 1: Usare Windows SChannel (scelta consigliata in Windows)

Configurare Git per l'uso dell'archivio certificati di Windows invece del relativo bundle openSSL CA. Se il certificato o la CA del server è attendibile da Windows, non sono necessari altri passaggi:

> git config --global http.sslBackend schannel

Per altre informazioni sulla configurazione del back-end SSL in Visual Studio, vedere Impostazioni Git - Provider di rete crittografico.

Opzione 2: Puntare Git sul certificato della CA

Esporta il certificato CA radice o intermedio come file codificato Base-64 .crt, quindi istruisci Git dove trovarlo:

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

È anche possibile aggiungere il certificato al bundle CA esistente di Git (in genere in C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) anziché eseguire l'override dell'intero bundle.

Per gli scenari dell'agente della pipeline con certificati autofirmati, vedere Eseguire un agente autogestito dietro un proxy o con certificati autofirmati.