Informazioni sul mapping dei comandi del controllo della versione di Team Foundation ai flussi di lavoro Git
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Si prevede di adottare Git, si ha familiarità con le azioni TFVC e ci si chiede come si esegue il mapping a Git? Entrambi sono sistemi di controllo del codice sorgente potenti e maturi. Tuttavia, il mapping delle azioni comuni a cui si è abituati nell'uno all'altro può essere un'esperienza confusa.
Questo articolo non illustra in modo approfondito i comandi Git, come sono ben documentati nella documentazione del prodotto, ma mostra esempi che consentono di prendere le decisioni giuste, durante lo spostamento in un tipico processo di creazione -> clone - ramo ->> modifica -> commit -> flusso di lavoro push.
Iniziare all'inizio creando un nuovo repository
Ogni progetto può ospitare repository TFVC e Git nello stesso progetto, creando un tfvc e uno o più repository Git.
Dopo aver creato il repository, vengono visualizzate istruzioni dettagliate per iniziare rapidamente.
Fare clic su Crea un file ReadMe alla fine della pagina di istruzioni per assegnare al repository il contesto e creare una cronologia.
Creare un'area di lavoro e ottenere la versione più recente
Quando ci si connette a un repository TFVC per la prima volta, in genere si crea un'area di lavoro e si ottiene il codice più recente. Quindi, come si inizia a usare Git?
Analogamente a un'area di lavoro in TFVC, il clone repository Git viene eseguito in una cartella nel computer. La clonazione scaricherà tutti i contenuti e la cronologia del repository nel computer locale. Dopo aver ottenuto il repository clonato, quasi tutte le operazioni vengono eseguite in locale. È possibile lavorare offline con un backup completo del repository centralizzato.
git clone https://dev.azure.com/demo-fabrikam/Fabrikam/_git/Mapping-TFVC-actions-to-Git
È necessario clonare una sola volta per ogni repository, ma come le aree di lavoro TFVC, è possibile avere più cloni per isolare il lavoro in corso. Tuttavia, la diramazione è in genere un modo migliore per isolare le modifiche.
Creare un ramo
Con Git, si lavora sempre in un ramo e per impostazione predefinita nelmain ramo . È consigliabile creare più rami locali. Si tratta di un processo che richiede secondi e consente di passare facilmente dal contesto tra rami e lavorare in isolamento. A differenza dei rami TFVC, che hanno come ambito percorsi, i rami Git hanno come ambito repository. Sono leggeri, possono essere solo locali o condivisi con altri utenti quando si è pronti a condividere le modifiche.
Prendere in considerazione la creazione di rami se è necessario lavorare in isolamento, sospendere il lavoro, concentrarsi sulle nuove funzionalità o se si prevede di eseguire una richiesta pull Git.
Come utente TFVC, ripetere alcune volte:
- La diramazione è consigliata.
- Il ramo Git è economico, veloce e potente.
- Git incoraggia l'utente a usare rami locali .
- Pubblicare rami locali nel repository centralizzato in base alle esigenze.
- Verificare sempre il contesto del ramo prima di apportare modifiche.
- Denominare il ramo usando una convenzione comune, ad esempio users/alias/branchname: users/doris/newfeature
Creare e passare a un ramo di argomento locale, denominato francis/demo-feature. È consigliabile eseguire un git status primo, per verificare che si sia nel ramo di destra con cui iniziare.
git checkout -b francis/demo-feature
Apportare una modifica aggiungendo file
Analogamente all'esperienza TFVC, i nuovi file nella cartella di lavoro non fanno automaticamente parte del repository. È possibile preparare i nuovi file con il git add comando , che è sinonimo di eseguire un'operazione add Items to Folder in TFVC.
git add <file>
or
git add --all
Usando l'esempio pre-bak, saranno disponibili 13 nuovi file che sono stati inclusi e sottoposti a staging nel repository locale.
Visualizzare le modifiche in sospeso
Domandarsi quali cambiamenti sono ora seduti nell'ambiente di lavoro? Come in precedenza, il comando Git status o la Changes visualizzazione nell'IDE di Visual Studio mostrerà le modifiche nell'albero di lavoro.
git status
Archiviare le modifiche e il commit in locale
In TFVC le modifiche vengono condivise con un'archiviazione, che invia le modifiche in sospeso al server. Il processo Git è leggermente diverso. Prima di tutto, si esegue il commit nel repository locale, creando un oggetto commit (ad esempio un insieme di modifiche), quindi si esegue il push per inviare tali modifiche al server.
Si esegue il commit delle modifiche nel repository locale usando git commit, in modo simile a in Checkin Pending Changes TFVC. Una differenza fondamentale è che esegue il git commit commit delle modifiche nel repository locale anziché nel repository remoto .
git commit
Controllare le modifiche con il server/repository remoto
Prima di tutto è necessario pubblicare il ramo locale francis/demo-feature nel server remoto, che include tutte le modifiche di cui è stato eseguito il commit.
git push --set-upstream origin francis/demo-feature
Per sincronizzare altri aggiornamenti nel repository locale con il repository remoto, è necessario eseguire il push delle modifiche usando git push. La procedura consigliata consiste nell'usare il comando Git o l'IDE di Visual Studio:
fetchper scaricare il contenuto e visualizzare in anteprima le modifiche in ingresso da altri utenti.pullper scaricare e quindi unire le modifiche da altri utenti.pushper condividere le modifiche locali.
Visualizza storico
Per visualizzare il commit, è stato appena creato è possibile esaminare la cronologia locale.
Per una cronologia compatta, usare:
git log --oneline
Per una visualizzazione dettagliata, usare:
git log
Come illustrato in precedenza, git log elenca l'autore, il messaggio di posta elettronica, la data scritta e il checksum SHA-1 di commit. Un utente TFVC può voler usare l'opzione --stat per includere altre informazioni, ad esempio il nome file e modificare le statistiche.
È anche possibile visualizzare la cronologia del repository centralizzato usando il portale Web di Azure DevOps Services.
Nel portale Web di Azure DevOps Services scegliere Cronologia CODICE o Cronologia > esplora CODICE > >
A questo punto, è stato esplorato correttamente il flusso di lavoro create -> clone - branch -> change ->> commit -> push, in base alle azioni TFVC comuni.
È anche possibile eseguire una richiesta pull per pubblicare e preparare le modifiche nel repository server/remoto a questo punto.
Altre azioni
Cambiare ramo
Quando si usa Git, non si modificano i rami passando a cartelle e posizioni separate nel computer. Modificare il contesto eseguendo un oggetto checkout, rendendo l'intera directory di lavoro corrispondente al ramo o al commit selezionato. Veloce e semplice!
Riga di comando
git checkout <branch>
Se si dimenticano i rami presenti nel repository locale, usare git branch per elencare i rami predefiniti e noti.
Tenere presente quale ramo si sta lavorando! Quando si usano più rami in Git, si passano rami nella stessa directory di lavoro. Il passaggio da un ramo all'altro è un'operazione veloce e assicurarsi di essere sempre nel ramo corretto è una procedura consigliata.
Ottenere la versione più recente
Ci sono molti motivi per cui si vogliono ottenere gli aggiornamenti. Ad esempio, quando è necessario passare dal contesto a un altro progetto, aggiornare il computer di sviluppo con la versione più recente della codebase.
Riga di comando
git pull
or
git fetch
seguito da
git merge FETCH_HEAD
Ottenere sempre la versione più recente e risolvere i conflitti di unione in locale.
Annullare le modifiche locali
Potrebbe esserci un motivo valido per ripristinare tutte le revisioni apportate nel repository locale e reimpostare l'ambiente di lavoro alla versione più recente dal repository remoto.
Riga di comando
git reset --hard HEAD
seguito da
git pull origin
seguito da
git clean -xdf
Lo scenario è sinonimo di eseguire con Get > Latest Version le Overwrite writable files that are not checked out opzioni e Overwrite all files if the local version matches the specified version in TFVC.
In alternativa, è possibile eliminare manualmente il repository locale, dopo aver eseguito una copia convalidata, e quindi clone nuovamente il repository.
Sono disponibili molte altre azioni e opzioni per gli utenti Git. Ecco alcuni siti di riferimento utili per altre informazioni:
- I comandi Git trattati in questo documento, fare riferimento alla documentazione git
- Si pensi a (a) Git, una guida per i perplessi.
- Come annullare (quasi) qualsiasi cosa con Git, di Joshua Wehner
Domande e risposte
Che ne dici della sincronizzazione?
"L'IDE Commit and Sync di Visual Studio non esegue magicamente tutto questo?"
Selezionare Commit Git>o Stash per aprire Modifiche Git. Selezionare il menu a discesa Commit All (Esegui commit tutto ), quindi selezionare Commit all and Sync (Esegui commit tutto e sincronizzazione).
In alternativa, in Team Explorer selezionare il menu a discesa Commit e quindi Comando e sincronizzazione.
Con la magia arriva la responsabilità! Molti utenti non amano perché sync a volte possono creare confusione nella cronologia locale e aggiungere un commit di merge sopra il commit corrente. Quando si è in uno stato non valido, è necessario ripristinare la riga di comando perché attualmente non è disponibile alcun supporto per la reimpostazione nell'IDE.
Autori: Jesse Houwing, Martin Hinshelwood, Mike Fourie e Willy Schaub dell'ALM | DevOps Rangers. Connettiti con loro qui.
(c) 2015 Microsoft Corporation. Tutti i diritti sono riservati. Questo documento viene fornito "così come è". Le informazioni e le visualizzazioni espresse in questo documento, inclusi URL e altri riferimenti al sito Web Internet, possono cambiare senza preavviso. L'utente si assume tutti i rischi derivanti dal loro utilizzo.
Questo documento non concede alcun diritto legale su qualsiasi proprietà intellettuale di qualsiasi prodotto Microsoft. È consentito copiare e utilizzare il presente documento solo a scopo di riferimento interno.