Informazioni sui rami e sui criteri dei rami

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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 per la denominazione per i 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.

Criteri

Predefinita

Descrizione

Richiedere un numero minimo di revisori

Disattivato

Richiedere l'approvazione da un numero specificato di revisori nelle richieste pull.

Verificare la presenza di elementi di lavoro collegati

Disattivato

Incoraggiare la tracciabilità controllando la presenza di elementi di lavoro collegati nelle richieste pull.

Verificare la risoluzione dei commenti

Disattivato

Verificare che tutti i commenti siano stati risolti nelle richieste pull.

Limitare i tipi di unione

Disattivato

Controllare la cronologia dei rami limitando i tipi di merge disponibili al termine delle richieste pull.

Aggiungere criteri di convalida della compilazione

Disattivato

Aggiungere uno o più criteri per convalidare il codice mediante l'unione preliminare e la compilazione delle modifiche delle richieste pull. Può anche abilitare o disabilitare i criteri.

Aggiungere criteri di controllo dello stato

Disattivato

Aggiungere uno o più criteri per richiedere ad altri servizi di pubblicare lo stato corretto per completare le richieste pull. Può anche abilitare o disabilitare i criteri.

Revisori inclusi automaticamente

Disattivato

Aggiungere uno o più criteri per designare i revisori del codice da includere automaticamente quando le richieste pull modificano determinate aree di codice. Può anche abilitare o disabilitare i criteri.

Adottare una strategia di creazione di rami Git

Nel repository sono presenti alcuni rami critici che il team si basa su una buona forma, ad esempio il main ramo.

Richiedere le richieste pull per apportare modifiche a questi rami. Il push delle modifiche effettuato dagli sviluppatori direttamente ai rami protetti verrà rifiutato.

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. Mantenere un ramo principale di alta qualità e aggiornato.

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.

Suddividere il lavoro in rami

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

Il commit delle 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 di funzionalità e correzioni di bug.

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

L'isolamento del lavoro nei rami semplifica la modifica di ciò che si sta lavorando modificando il ramo corrente.

Come vengono creati i rami Git?

I rami vengono creati usando il branch comando . 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 rilevamento upstream semplifica la sincronizzazione delle modifiche con altri utenti usando il push e il pull.

Oggetto visivo di un ramo off main in Git

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 entrambi i rami.

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 checkout comando . 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, è possibile eseguire il push delle modifiche per aggiornare il ramo remoto.

Un errore comune consiste nell'apportare alcune modifiche, commit rendersi conto che si è in un ramo non corretto, quindi checkout nel 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 selezionare cherry-pick dei commit dal ramo o unire 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 esegue 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 è necessario più di un repository nel sistema quando si usano rami per isolare il lavoro.

Configurare l'ambiente di sviluppo una volta dopo la clonazione. Usare quindi i rami Git per scambiare tra il lavoro delle funzionalità e la correzione di bug.

Diramazione delle guide

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