Applicare le modifiche con rebase

2025-03-27

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

Visual Studio 2019 | Visual Studio 2022

Git gestisce automaticamente una cronologia di sviluppo su un branch collegando ogni nuovo commit al predecessore. Quando si unisce un ramo a un altro, la cronologia può diventare meno semplice. Ad esempio, un merge senza avanzamento rapido combina linee di sviluppo divergenti creando un commit di merge con più predecessori. Al contrario, un rebase di Git unisce linee di sviluppo divergenti senza creare un commit di merge, il che si traduce in una cronologia dei commit più semplice ma comporta la perdita di informazioni sulla fusione. La scelta di tipo di unione è probabilmente influenzata dal fatto che si voglia mantenere un record dell'unione o semplificare la cronologia dei commit.

Questo articolo illustra quando usare il rebase anziché un merge non fast-forward e fornisce le procedure per le attività seguenti:

Riorganizza il ramo locale
Forzare il push del branch locale dopo un rebase
Rebase interattivo per eseguire il squash dei commit locali

Per una panoramica del flusso di lavoro Git, vedere il tutorial Git di Azure Repos.

Prerequisiti

Categoria	Requisiti
Accesso al progetto	Membro di un progetto.
Autorizzazioni	- Visualizzare il codice nei progetti privati: almeno livello di accesso Basic . - Clonare o contribuire al codice nei progetti privati: membro del gruppo di sicurezza Contributors o con autorizzazioni corrispondenti nel progetto. - Impostare le autorizzazioni per il ramo o il repository: Gestisci le autorizzazioni per il ramo o il repository. - Modificare il ramo predefinito: Modificare le politiche le autorizzazioni per il repository. - Importare un repository: membro del gruppo di sicurezza , amministratori del progetto, o del gruppo di sicurezza Git a livello di progetto , Crea repository impostato su Consenti. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git.
Servizi	Repos abilitato.
Strumenti	Opzionale. Usare i comandi az repos: l'interfaccia della riga di comando di Azure DevOps.

Nota

Nei progetti pubblici, gli utenti con accesso Stakeholder hanno pieno accesso ad Azure Repos, compresa la visualizzazione, la clonazione e il contribuire al codice.

Categoria	Requisiti
Accesso al progetto	Membro di un progetto.
Autorizzazioni	- Visualizzare il codice: almeno accesso di base. - Clonare o contribuire al codice: membro del gruppo di sicurezza Contributor o autorizzazioni corrispondenti nel progetto.
Servizi	Repos abilitato.

Eseguire nuovamente il database del ramo locale

Git rebase integra i commit da un ramo di origine nel ramo locale corrente (ramo di destinazione). Il ramo di origine rimane invariato. Per il confronto, il rebase Git e altri tipi di merge sono illustrati nel diagramma seguente.

Diagramma che mostra i commit prima e dopo quando si usa git rebase.

Git rebase riorganizza la cronologia dei commit del ramo di destinazione in modo che contenga tutti i commit del ramo di origine, seguiti da tutti i commit del ramo di destinazione dall'ultimo commit comune. Un altro modo per visualizzarlo è che un rebase riproduce le modifiche nel ramo di destinazione sulla cronologia del ramo di origine. In particolare, git rebase modifica la sequenza dei commit del ramo di destinazione esistente, che non è il caso per le altre strategie di merge. Nel diagramma precedente, commit K' contiene le stesse modifiche di K, ma ha un nuovo ID commit perché si collega di nuovo al commit E invece di C.

Durante una rebase, se una modifica del ramo di origine entra in conflitto con una modifica del ramo di destinazione, Git richiederà di risolvere il conflitto di fusione. È possibile risolvere i conflitti di merge durante un rebase nello stesso modo in cui si risolvono i conflitti di merge durante un merge.

Rebase e merge senza avanzamento veloce

Il rebasing git comporta una cronologia di commit più semplice ma meno esatta rispetto a un'unione senza con inoltro rapido, altrimenti nota come a tre vie o vera merge. Quando si desidera un record di un'unione nella cronologia dei commit, usare un'unione senza avanzamento rapido.

Se sei l'unica persona che lavora su una feature o un branch di bugfix, prendi in considerazione l'uso di un rebase per integrare periodicamente il lavoro recente del branch main. Questa strategia consente di assicurarsi di essere consapevoli del lavoro recente da parte di altri utenti e di risolvere tempestivamente eventuali conflitti di merge che si verificano. Ribasando, si implementa la nuova funzionalità sopra il lavoro più recente del ramo main, il che consente di mantenere una cronologia di commit lineare.

Per altre informazioni su Git rebase e su quando usarlo, vedere Rebase vs merge.

Linee guida per il rebase e il push forzato

Se si ristruttura un ramo locale di cui è stato eseguito il push , e quindi si esegue di nuovo il comando git push predefinito, il push avrà esito negativo. Il comando push Git predefinito applica un merge fast forward per integrare il ramo locale nel ramo remoto. Questo comando avrà esito negativo dopo un rebase perché il rebase modifica la sequenza dei commit esistenti nel ramo di destinazione locale, per cui non corrisponde più alla cronologia della sua controparte remota. In questo scenario, un forza push avrà esito positivo, sovrascrivendo il ramo remoto.

Git rebase e force push sono strumenti potenti, ma tenere presenti queste linee guida quando si decide se usarle:

Non basare nuovamente un ramo locale di cui è stato eseguito il push e condiviso con altri utenti, a meno che non si sia certi che nessuno stia usando il ramo condiviso. Dopo un rebase, il ramo locale non corrisponderà più alla cronologia della sua controparte remota.
Non forzare il push in un ramo remoto usato da altri utenti, poiché la versione locale del ramo remoto non corrisponderà più alla cronologia dei rami remoti aggiornata.
Il tuo team dovrebbe concordare sugli scenari di utilizzo per rebase e force push.

Suggerimento

Per un processo di revisione collaborativa, utilizzare una pull request per integrare un nuovo lavoro nel ramo predefinito di un repository remoto.

Come eseguire il rebase

Visual Studio 2022 offre un'esperienza di controllo della versione Git usando il menu Git, Le modifiche Git e tramite i menu di scelta rapida in Esplora soluzioni. Visual Studio 2019 versione 16.8 offre anche l'interfaccia utente Git di Team Explorer . Per altre informazioni, vedere la scheda Visual Studio 2019 - Team Explorer .

Scegliere Git Gestisci branche > per aprire la finestra repository Git.
Nella finestra repository Git fare clic con il pulsante destro del mouse sul ramo di destinazione e selezionare Checkout.
Fare clic con il pulsante destro del mouse sul ramo di origine e selezionare Rebase <ramo di destinazione> su <ramo di origine>.
Visual Studio visualizzerà un messaggio di conferma al termine di un rebase riuscito.

Se la rebase viene interrotta a causa di conflitti di merge, Visual Studio invierà una notifica. Puoi risolvere i conflittioppure annullare il rebase e tornare allo stato prima della rebase.

Per integrare i commit del ramo di origine in un ramo di destinazione, eseguire il comando git rebase:

git rebase <source branch name> <target branch name>

Se il ramo locale corrente è il ramo di destinazione, è possibile semplificare il comando rebase per:

git rebase <source branch name>

Git notificherà in caso di conflitti durante il rebase. È possibile risolvere i conflitti e quindi eseguire git rebase --continueoppure eseguire git rebase --abort per annullare il rebase e tornare allo stato di pre-rebase.

Eseguire un push forzato del branch locale dopo un rebase

Se si esegue il rebase di un ramo locale di cui è stato eseguito il push in precedenza, un push Git predefinito successivo avrà esito negativo. È invece possibile forzare il push del ramo locale per sovrascrivere la controparte remota in modo che le cronologie di commit corrispondano.

Avvertimento

Non forzare mai il push di un ramo su cui altri stanno lavorando. Per ulteriori informazioni, vedere le linee guida su rebase e force push e.

Per forzare il push in Visual Studio, è prima necessario abilitare l'opzione force push:

Vai a Strumenti>Opzioni>Controllo del Codice Sorgente>Impostazioni Globali Git.
Selezionare l'opzione di abilitazione del push --force-with-lease.

Il flag git push --force-with-lease è più sicuro del flag --force perché non sovrascrive un ramo remoto con commit che non sono integrati all'interno del ramo locale di cui si forza il push.

Nella finestra modifiche Git, seleziona il pulsante push per eseguire il push del commit.

In alternativa, è possibile selezionare Push dal menu Git.
Se l'operazione push Git predefinita non riesce, Visual Studio avvia la finestra di dialogo Git-Push non riuscita. Scegliere Force Push.
Visual Studio visualizzerà un messaggio di conferma dopo un push riuscito.

Suggerimento

Il flag git push --force-with-lease è più sicuro del flag --force perché non sovrascrive un ramo remoto con commit che non sono integrati all'interno del ramo locale di cui si forza il push.

Per forzare il push di nuovi commit dal branch locale a un branch remoto con lo stesso nome:

git push --force-with-lease <remote> <local branch name>

Se il ramo di cui si vuole eseguire il push è il ramo estratto, è possibile semplificare il comando force push in:

git push --force-with-lease <remote>

Quando si clona un repository remoto, Git assegna l'alias origin come abbreviato per l'URL del repository remoto clonato. Eseguire git remote -v per controllare il valore alias origin. Per aggiungere manualmente l'alias origin, eseguire git remote add origin <remote repo url>. Con l'alias origin, è possibile semplificare ulteriormente il comando force push:

git push --force-with-lease origin

Se il ramo locale corrente tiene traccia di un ramo remoto in origin, è possibile abbreviare completamente il comando force push:

git push --force-with-lease

Tuttavia, il comando push completamente abbreviato avrà esito negativo se il ramo locale non tiene traccia di un ramo remoto. Esegui git remote show origin per controllare lo stato rilevato delle branche.

Rebase interattivo per eseguire il squash dei commit locali

In genere, mentre si lavora su una nuova funzionalità nel ramo di funzionalità locale, si creeranno più commit. Quando si è pronti per pubblicare la nuova funzionalità, è possibile consolidare tali commit in un unico commit per semplificare la cronologia dei commit. È possibile usare una rebase interattiva per comprimere più commit in un singolo commit.

Visual Studio 2022 non supporta il rebasing interattivo. Usare invece la riga di comando Git.

Passa al ramo locale su cui si vuole eseguire una ribase interattiva.
Commit, stash o rimuovere eventuali modifiche di cui non è stato eseguito il commit.
Stimare quanto indietro nella cronologia dei commit si desidera andare. Non è necessario essere precisi perché potrai selezionare specifici commit da unire quando esegui il comando rebase interattivo. Ad esempio, se si desidera comprimere i commit negli ultimi cinque commit, eseguire:
```
git rebase -i HEAD~5
```
Git aprirà un editor che elenca gli ultimi cinque commit, a partire dall'ultima versione. Per esempio:
```
pick 7068b09 Update README network switch section
pick 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
pick 00859d9 Add network controller test
```
Lasciare invariata la prima riga. Nelle righe successive, per unire un commit con quello precedente, modificare pick in squash. Ad esempio, per combinare i primi due commit e anche i due commit inferiori, modificare l'elenco di commit in:
```
pick 7068b09 Update README network switch section
squash 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
squash 00859d9 Add network controller test
```
Salvare e chiudere l'editor. Git aprirà quindi un nuovo editor per ogni set di commit uniti, richiedendo di immettere un messaggio di commit. Per ogni set di commit, condensare i messaggi di commit in un solo messaggio, quindi salvare e chiudere l'editor. Nell'esempio precedente, i commit compressi vengono condensati con nuovi messaggi di commit:
```
8fcb88f Update README network sections
ac6d3c0 Fix fiber optic transmitter test
f0aadc3 Add two network tests
```
Anche se il commit Fix fiber optic transmitter test non è stato compresso, ha un nuovo ID commit perché ora si collega a un commit predecessore diverso.

Per ulteriori informazioni sul rebasing interattivo, vedere modalità interattiva di git rebase.

Nota

Gli utenti di Azure DevOps possono merge di squash per condensare la cronologia dei commit di un ramo di argomento durante una richiesta pull.

Passaggi successivi

Modifiche copiate con cherry-pick