Informazioni sui rami e le politiche dei rami

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

I criteri di ramo sono una parte importante del flusso di lavoro Git e consentono di:

• Isolare il lavoro in corso dal lavoro completato nel ramo principale
• Garantire la compilazione delle modifiche prima di arrivare a main
• Limitare gli utenti che possono contribuire a rami specifici
• Imporre chi può creare rami e le linee guida di denominazione dei rami
• Includere automaticamente i revisori corretti per ogni modifica del codice
• Applicare le procedure consigliate con i revisori del codice necessari

La tabella seguente riepiloga i criteri che è possibile definire per personalizzare un ramo. Per una panoramica di tutti i criteri e le impostazioni dei repository e dei rami, vedere Impostazioni e criteri del repository Git.

Adottare una strategia di diramazione Git

Nel tuo repository sono presenti alcuni rami critici sui quali il team fa affidamento perché siano sempre in uno stato affidabile, come ad esempio il ramo main.

Richiedi richieste pull per apportare modifiche a questi rami. Gli sviluppatori che eseguono il push delle modifiche direttamente nei rami protetti avranno i push rifiutati.

Per semplificare la strategia dei rami, creare la strategia da questi tre concetti:

1. Usare i rami feature per tutte le nuove funzionalità e le correzioni di bug.
2. Unire rami di funzionalità nel ramo principale usando le richieste pull.
3. Mantieni un ramo principale aggiornato e di alta qualità up-to.

Una strategia che estende questi concetti ed evita contraddizioni comporta un flusso di lavoro di controllo della versione per il team coerente e facile da seguire.

• Adottare una strategia di diramazione
• Come configurare i criteri dei rami
• Autorizzazioni per i rami
• Richiedi cartelle di filiali
• Configurare un criterio di filiale per un servizio esterno

Creare il lavoro nei rami

I rami Git non sono molto più di un piccolo riferimento che mantiene una cronologia esatta dei commit, quindi sono economici da creare.

Commettere le modifiche in un ramo non influisce su altri rami. È possibile condividere rami con altri utenti senza dover unire le modifiche nel progetto principale.

È possibile creare nuovi rami per isolare le modifiche per una funzionalità o una correzione di bug dal ramo principale e da altre attività.

Poiché i rami sono leggeri, il passaggio tra rami è semplice e rapido. Git non crea più copie dell'origine quando si usano rami, ma usa le informazioni di cronologia archiviate nei commit per ricreare i file in un ramo quando si inizia a lavorare su di esso.

Il flusso di lavoro Git deve creare e usare rami per la gestione delle funzionalità e delle correzioni di bug.

Il resto del flusso di lavoro Git, ad esempio condivisione del codice e la revisione del codice con pull request funzionano tramite rami.

L'isolamento del lavoro nei rami semplifica il passaggio da un'attività all'altra cambiando il ramo corrente.

Come vengono creati i rami Git?

Per creare rami, usare il comando branch. Branch crea un riferimento in Git per il nuovo ramo e un puntatore al commit padre in modo che Git possa mantenere una cronologia delle modifiche man mano che si aggiungono commit al ramo.

Quando si lavora con un ramo condiviso da un altro utente, Git mantiene una relazione di rilevamento upstream. La relazione associa il ramo nel repository locale al ramo corrispondente nel repository remoto.

Il tracciamento upstream rende semplice sincronizzare le modifiche con altri usando il comando push e il comando pull.

In questo screenshot è possibile visualizzare un nuovo ramo creato dal ramo principale. Il lavoro continua su entrambi i rami e i commit vengono aggiunti a ciascuno di essi.

Git aggiunge sempre nuovi commit al ramo locale corrente. Controllare il ramo su cui si sta lavorando prima di eseguire il commit in modo da non eseguire il commit delle modifiche nel ramo errato.

Scambiare tra rami locali usando il comando checkout. Git modificherà i file nel computer in modo che corrispondano al commit più recente nel ramo estratto.

Quando il lavoro nel ramo è pronto per la condivisione con il resto del team, esegui il push delle modifiche per aggiornare il ramo remoto.

Un errore comune consiste nell'effettuare alcune modifiche e commit, renderti conto che sei su un ramo sbagliato, quindi checkout al ramo corretto.

Le modifiche più recenti non saranno più presenti nel file system perché ogni ramo ha una propria versione di codice.

Git riporta lo stato dei file all'ultimo commit nel ramo in cui è stato scambiato, non nel ramo precedente in cui sono state apportate le modifiche.

Sarà necessario cherry-pick i commit dal ramo o integrare le modifiche nel ramo corretto.

Usare rami per gestire lo sviluppo

Git tiene traccia del ramo su cui si sta lavorando e assicura che quando si checkout un ramo i file corrispondano al commit più recente nel ramo.

I rami consentono di usare più versioni del codice sorgente nello stesso repository Git locale contemporaneamente.

Indicare a Git quale ramo si vuole usare con checkoute Git si occupa dell'impostazione delle versioni di file corrette per tale ramo.

Non hai bisogno di più di un repository sul sistema quando usi branch per isolare il tuo lavoro.

Configurare l'ambiente di sviluppo una sola volta dopo aver clonato. Usare quindi i rami Git per passare tra il lavoro sulle funzionalità e la correzione di bug.

Diramazione delle guide

Informazioni su come completare le attività comuni quando si lavora con i rami.

• Tutorial sui rami
• Come creare un ramo
• Come eliminare un ramo
• Ripristinare un ramo eliminato
• Come bloccare i rami

Articoli correlati

• Migliora la qualità del codice con i criteri di diramazione
• Impostazioni e criteri del repository Git
• Configurare i criteri del repository Git usando un file di configurazione
• Autorizzazioni Git predefinite (sicurezza)
• Impostare le autorizzazioni (sicurezza)
• Panoramica dell'integrazione tra servizi