Salvare e condividere codice con Git

Il salvataggio e la condivisione di versioni del codice con un team sono le operazioni più comuni eseguite quando si usa il controllo della versione. Git offre un flusso di lavoro semplice in tre passaggi per queste attività:

1. Creare un nuovo ramo per il lavoro
2. Eseguire il commit delle modifiche
3. Eseguire il push del ramo per condividerlo con il team

Git semplifica la gestione del lavoro usando i rami. Ogni bugfix, nuova funzionalità, test aggiunto e configurazione aggiornata inizia con un nuovo ramo. I rami sono leggeri e locali nel computer di sviluppo, quindi non è necessario preoccuparsi di usare le risorse o coordinare le modifiche con altri fino a quando non è il momento di eseguire il push del ramo.

I rami consentono di scrivere codice in isolamento da altre modifiche nello sviluppo. Una volta che tutto funziona, il ramo e le relative modifiche vengono condivisi con il team. Altri utenti possono sperimentare il codice nella propria copia del ramo senza influire sul lavoro in corso nei propri rami.

Creare un ramo

Creare un ramo in base al codice in un ramo corrente, ad esempio main, all'avvio di un nuovo lavoro. È consigliabile verificare quale ramo è selezionato usando git status prima di creare un nuovo ramo.

Creare rami in Git usando il git branch comando :

> git branch <branchname>

Il comando da scambiare tra rami nel repository è git checkout. Dopo aver creato il ramo, passare a esso prima di salvare le modifiche.

> git checkout <branchname>

Git ha un comando abbreviato per creare il ramo e passare al ramo contemporaneamente:

> git checkout -b <branchname>

Altre informazioni sull'uso dei rami Git in GitHub o Azure DevOps.

Salvare le modifiche

Git non esegue automaticamente lo snapshot del codice man mano che vengono apportate modifiche. Git deve essere indicato esattamente quali modifiche aggiungere allo snapshot successivo. Questa operazione è denominata staging. Dopo la gestione temporanea delle modifiche, creare un commit per salvare lo snapshot in modo permanente.

Modifiche di fase

Git tiene traccia delle modifiche apportate al file nel repository man mano che si verificano. Separa queste modifiche in tre categorie:

• I file non modificati non sono stati modificati dopo l'ultimo commit.
• I file modificati hanno modifiche dopo l'ultimo commit, ma non sono state preparate per il commit successivo.
• I file di staging presentano modifiche che verranno aggiunte al commit successivo.

Quando si crea un commit, vengono usate solo le modifiche a fasi e i file non modificati per lo snapshot. Le modifiche non salvate vengono mantenute nel file system, ma il commit usa il file non modificato nello snapshot.

Eseguire il commit delle modifiche

Salvare le modifiche in Git creando un commit. Ogni commit archivia il contenuto completo del file del repository in ogni commit, non solo le singole modifiche ai file. Questo comportamento è diverso da altri sistemi di controllo della versione che archivia le differenze a livello di file rispetto all'ultima versione del codice. Le cronologie dei file complete consentono a Git di prendere decisioni migliori durante l'unione delle modifiche e di passare rapidamente tra rami di codice.

Modificare le fasi con git add per aggiungere file modificati, git rm rimuovere i file e git mv spostare i file. Usare git commit quindi il comando per creare il commit.

In genere, gli sviluppatori vogliono preparare tutti i file modificati nel repository:

> git add –all

Eseguire quindi il commit delle modifiche con una breve descrizione:

> git commit -m "Short description of changes."

Ogni commit contiene un messaggio che ne descrive le modifiche. Un buon messaggio di commit consente allo sviluppatore di ricordare le modifiche apportate in un commit. I messaggi di commit validi semplificano anche la revisione del commit da parte di altri utenti.

Altre informazioni sui file di staging e sul commit delle modifiche in Visual Studio o Visual Studio Code.

Condividere le modifiche

Sia che si lavori su un team o si voglia semplicemente eseguire il backup del proprio codice, gli sviluppatori devono condividere i commit con un repository in un altro computer. Usare il git push comando per eseguire i commit dal repository locale e scriverli in un repository remoto. Git è configurato in repository clonati per connettersi all'origine del clone, noto anche come origin. Eseguire git push per scrivere i commit locali nel ramo corrente in un altro ramo (branchname) in questo repository di origine . Git crea il nome di ramo nel repository remoto, se non esiste.

> git push origin

Se si lavora in un repository creato nel sistema locale con git init, è necessario configurare una connessione al server Git del team prima di poter eseguire il push delle modifiche. Altre informazioni sulla configurazione di remote e sul push delle modifiche in Visual Studio o Visual Studio Code.

Condividere rami

Il push di un ramo locale nel repository condiviso del team rende le modifiche accessibili al resto del team. La prima volta git push che viene eseguita, l'aggiunta dell'opzione -u indica a Git di iniziare a tenere traccia del ramo locale al nome ramo dal origin repository. Dopo questa configurazione monouso delle informazioni di rilevamento, i membri del team possono usare git push direttamente per condividere gli aggiornamenti in modo rapido e semplice.

> git push origin <branchname>

Passaggi successivi

Altre informazioni sui rami in GitHub o Azure DevOps.

Altre informazioni sul push di commit e rami in Visual Studio o Visual Studio Code.