Domande frequenti su Git

Prima di tutto, assicurarsi di avere configurato un origin repository. Se il repository è stato clonato git clone, è necessario disporre di tale repository. Quando si estrae un ramo che non esiste in locale, Git determina se è presente un ramo remoto con lo stesso nome. In caso affermativo, Git crea un ramo locale con un riferimento al ramo remoto di tale nome. Usare git pull per scaricare i commit e recuperare Git nella cronologia dei rami in locale.

git branch senza argomenti vengono visualizzati i rami locali ed evidenzia quelli che sono stati estratti. In Visual Studio la barra di stato visualizza anche il ramo corrente quando si usa un progetto archiviato in un repository Git locale.

La pratica accettata consiste nell'effettuare commit separati per modifiche separate logicamente. 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'opzione comune consiste nel consentire a tutti di eseguire il commit in locale come si vuole, ma prima di eseguire il push dei commit locali, questi vengono prima sottoposti a rebasing. Questa opzione offre agli utenti la flessibilità necessaria per eseguire frequenti commit, mantenendo la cronologia dei commit semplificata.

Progetti di grandi dimensioni con molti commit e una gamma di collaboratori può comportare cronologie di commit per il main ramo che rappresenta la cronologia di sviluppo dei rami dell'argomento uniti in main più della cronologia di sviluppo del progetto complessivo. Git offre una funzionalità per condensare i commit nei rami tramite commit di squash e ribasing. Quando si esegue il commit di squash, la cronologia dei commit in un ramo diventa meno dettagliata, che rende più semplice la cronologia dei commit nel ramo principale 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 foo.js -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Francis Totten 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 mostrerà una cronologia di commit completa per il file nel ramo corrente.

L'estrazione in un ramo diverso in Git influirà 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.

A volte si vogliono mantenere le modifiche, ma non eseguirne il commit perché non sono in un punto in cui si è a proprio agio. Usare Git stash. Stash accetta le modifiche correnti di staging e non preparate nel ramo e salva il lavoro, quindi restituisce il ramo allo stato dell'ultimo commit. È possibile passare all'altro ramo, eseguire il lavoro, quindi quando si torna a questo ramo 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ù di recente verranno applicate al ramo corrente. Se si verifica un conflitto durante l'applicazione delle modifiche non sincronizzate, stash ripristinerà le modifiche per i file che non sono in conflitto e creerà marcatori di conflitto nei file in conflitto da risolvere. In questo caso, è consigliabile unire manualmente le modifiche.

Al termine dell'operazione, eliminarlo con git stash drop Questo comando rimuove l'ultimo set di modifiche non allineate.

È possibile avere più stashe, ma questa operazione richiede una manipolazione più manuale perché è necessario applicare e rilasciare in modo esplicito gli stashe. Altre informazioni sono disponibili nella documentazione di Git Stash.

Per impostazione predefinita, Git della riga di comando userà un editor della riga di comando quando viene richiesto il commit dei messaggi, l'esecuzione di 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 Windows Blocco note per modificare le informazioni Git in base alle esigenze e passare correttamente il testo da Git a 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 "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

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 Git Global Impostazioni o Git Repository Impostazioni> General.

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 globale o Repository Impostazioni.