Modificare il ramo predefinito

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

Il ramo predefinito è il primo ramo che Git eseguirà il check-out su un nuovo clone. Inoltre, le richieste pull hanno come destinazione questo ramo per impostazione predefinita.

Verrà illustrato il processo di modifica del ramo predefinito. Verranno illustrati anche altri aspetti da considerare e aggiornare quando si apporta questa modifica. Infine, verrà esaminato uno strumento per facilitare la transizione.

Impostare un nuovo ramo predefinito

È possibile usare un ramo diverso main da per le nuove modifiche o modificare la linea di sviluppo principale nel repository. Per modificare il nome predefinito del ramo per i nuovi repository, vedere Tutte le impostazioni e i criteri dei repository.

Per modificare il ramo predefinito del repository per unire nuove richieste pull, sono necessari almeno due rami. Se è presente un solo ramo, è già l'impostazione predefinita. Per modificare l'impostazione predefinita, è necessario creare un secondo ramo.

Nota

Per modificare il ramo predefinito è necessaria l'autorizzazione Modifica criteri . Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.

1. Nel repository del progetto selezionare Rami.

2. Nella pagina Rami selezionare Altre opzioni accanto al nuovo ramo predefinito desiderato e scegliere Imposta come ramo predefinito.

   

3. Dopo aver impostato il nuovo ramo predefinito, è possibile eliminare il valore predefinito precedente, se necessario.

Prima di apportare questa modifica, è necessario prendere in considerazione altri aspetti.

Scegliere un nome

Git 2.28 ha aggiunto la possibilità di scegliere un nome di ramo iniziale. Allo stesso tempo, Azure Repos, GitHub e altri provider di hosting Git hanno aggiunto la possibilità di scegliere un nome di ramo iniziale diverso. In precedenza, il ramo predefinito era quasi sempre denominato master. Il nome alternativo più diffuso è main. Le opzioni meno comuni includono trunk e development. Se non sono presenti restrizioni relative agli strumenti usati o al team in uso, qualsiasi nome di ramo valido funzionerà.

Aggiornare altri sistemi

Quando si passa a un ramo predefinito diverso, potrebbero essere interessate altre parti del flusso di lavoro. È necessario tenere conto di queste parti quando si pianifica una modifica.

Pipelines

Aggiornare i trigger di integrazione continua per tutte le pipeline. Le pipeline di progettazione possono essere modificate nel Web. Le pipeline YAML possono essere modificate nei rispettivi repository.

Richieste pull in anteprima

Ridestinare ogni richiesta pull aperta al nuovo ramo predefinito.

Cloni esistenti

I nuovi cloni del repository otterranno il nuovo ramo predefinito. Dopo l'opzione, tutti gli utenti con un clone esistente devono essere eseguiti git remote set-head origin -a (sostituendo origin con il nome del relativo remoto se si tratta di un altro elemento) per aggiornare la visualizzazione del ramo predefinito del remoto. I nuovi rami futuri devono essere basati sul nuovo valore predefinito.

Collegamenti in ingresso

Alcuni segnalibri, documenti e altri file non di codice che puntano ai file in Azure Repos dovranno essere aggiornati. Il nome del ramo per un file o una directory può essere visualizzato nell'URL.

Se un URL contiene una stringa di query per version, ad esempio &version=GBmybranchname, tale URL deve essere aggiornato. Fortunatamente, la maggior parte dei collegamenti al ramo predefinito non avrà un version segmento e può essere lasciata così come è. Inoltre, dopo aver eliminato il vecchio ramo predefinito, i tentativi di passarvi verranno comunque portati al nuovo valore predefinito.

Mirroring temporaneo

Un repository Git può avere un solo ramo predefinito. Tuttavia, per un po', è possibile configurare il mirroring ad hoc tra il valore predefinito precedente e il nuovo valore predefinito. In questo modo, se gli utenti finali continuano a eseguire il push al valore predefinito precedente, non dovranno ripetere il lavoro alla fine. Per configurare questo mirroring temporaneo si userà Azure Pipelines .

Nota

Questa sezione usa la lingua che è in contrasto con la prospettiva di Microsoft. In particolare, la parola master viene visualizzata in diverse posizioni coerente con il modo in cui è stata usata in Git. Lo scopo di questo argomento è spiegare come passare a un linguaggio più inclusivo, ad esempio main. Evitare tutte le menzioni di master renderebbe le direzioni molto più difficile da comprendere.

Pipeline di mirroring

Nota

Queste istruzioni non sono di tipo stupido e l'installazione del repository potrebbe richiedere modifiche aggiuntive, ad esempio autorizzazioni e criteri di sfusi.

Avviso

Se i rami predefiniti precedenti e nuovi vengono aggiornati prima dell'esecuzione di questa pipeline, la pipeline non sarà in grado di eseguire il mirroring delle modifiche. Un utente dovrà unire manualmente il ramo predefinito precedente nel nuovo ramo predefinito per eseguirlo di nuovo automaticamente.

1. Per tutte le build CI esistenti, aggiornarle in modo che vengano attivate in base al nuovo ramo predefinito anziché a quello precedente.

2. Concedere all'identità di compilazione l'autorizzazione Contribuire al repository. Passare a Project Impostazioni> Repositories>(your repo)>Permissions (Autorizzazioni del repository). Possono essere presenti fino a due identità, una per il servizio di compilazione della raccolta di progetti e l'altra per il servizio di compilazione del progetto. Assicurarsi che l'autorizzazione Di collaborazione sia consentita.

3. Se il nuovo ramo predefinito dispone di criteri di ramo, concedere anche all'identità di compilazione i criteri bypass durante il push dell'autorizzazione . Questa autorizzazione è un rischio per la sicurezza perché un utente malintenzionato potrebbe creare una pipeline per inserire codice in un repository nel progetto. Quando il mirroring non è più necessario, assicurarsi di rimuovere questa autorizzazione.

4. Aggiungere un nuovo file mirror.yml al repository nel nuovo ramo predefinito. In questo esempio si presuppone che il ramo predefinito precedente sia e master quello nuovo sia main. Aggiornare i rami di attivazione e la git push riga se i nomi dei rami sono diversi.

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

5. Creare una nuova pipeline, scegliendo "Azure Repos Git" e "File YAML di Azure Pipelines esistente" nella procedura guidata. Scegliere il mirror.yml file aggiunto nel passaggio precedente. Salvare ed eseguire la pipeline.

Risoluzione dei problemi

Questa pipeline verrà eseguita ogni volta che è presente un push in master o in main. Li manterrà sincronizzati finché i nuovi commit non arrivano contemporaneamente su entrambi i rami.

Se la pipeline inizia a non riuscire con un messaggio di errore simile a "Aggiornamenti sono stati rifiutati perché un suggerimento di ramo push è dietro il relativo remoto", un utente dovrà unire il ramo precedente nel nuovo ramo a mano.

1. Clonare il repository e cd nella relativa directory.
2. Vedere il nuovo ramo predefinito con git checkout main (se main è il nuovo ramo predefinito).
3. Creare un nuovo ramo per l'integrazione dei due rami con git checkout -b integrate.
4. Unire il ramo predefinito precedente con git merge master (se master è il ramo predefinito precedente).
5. Eseguire il push del nuovo ramo, quindi aprire e completare una richiesta pull nel nuovo ramo predefinito.
6. La pipeline di mirroring deve quindi occuparsi del mirroring del commit di merge nell'impostazione predefinita precedente.