Tutorial Git Rebase

I principianti di Git sono avvertiti contro il comando Rebase. E giustamente. Con tutte le cose nuove da imparare, i principianti stanno probabilmente meglio padroneggiare i concetti di base prima di approfondire. Tuttavia, se si comprende le basi della fusione dei rami, allora sapere come rebifase può aiutarti a risolvere alcuni puzzle di sviluppo complicati quando arriva il momento giusto.

Git Rebase: Definizioni

Secondo la documentazione GIT, il comando Rebase si impegnerà in cima a un'altra punta di base. Questa definizione potrebbe essere un po 'scoraggiante. È più facile spiegare Rebase come una procedura che aggiunge i cambiamenti del ramo corrente alla coda di un altro ramo. Cammiamo attraverso un esempio per avere un'idea migliore di ciò che accade.

Git REBASING ESEMPIO

In questo esempio, creeremo prima un caso di test con Branch "Master" e "Feature". Quindi faremo una fusione standard. Successivamente, ricretteremo il caso di prova ed eseguiremo Rebase e unire.

1. Creazione di rami master e di funzionalità

Ecco lo scenario che creeremo:

A - B - C (Master)

\

E - F (Feature)

Nell'esempio sopra, stiamo prendendo il seguente percorso:

1. Commetti A: aggiungiamo a.file txt nella filiale "master"

2. Commit b: aggiungiamo b.file txt nella filiale "master"

3. In questa fase, creiamo la "funzione" di ramo, il che significa che avrà un.txt e b.TXT

4. Commit c: aggiungiamo c.file txt nella filiale "master"

5. Andiamo al ramo "Feature"

6. Commit e: modifichiamo a.txt in 'Feature' Branch

7. Commit f: modifichiamo b.txt in 'Feature' Branch

È possibile creare una cartella ed eseguire il seguente codice all'interno della cartella per creare la situazione sopra:

git init
toccare a.TXT
git aggiungi -a
git commit -m "commit a: aggiunto a.TXT"
tocco b.TXT
git aggiungi -a
git commit -m "commit b: aggiunto b.TXT"
Funzione di filiale Git
Toccare C.TXT
git aggiungi -a
git commit -m "commit c: aggiunto c.TXT"
Stato Git
Funzione Git Checkout
echo aaa> a.TXT
git aggiungi -a
git commit -m "commit e: modificato a.TXT"
echo bbb> b.TXT
git aggiungi -a
git commit -m "commit f: modificato B.TXT"

---

2. Unisci semplice

Usiamo il comando di registro per controllare entrambi i rami.

Risultati per "Master":

$ git checkout master
Passato a Branch 'Master'
$ git log --oneline
2BBDE47 commit c: aggiunto c.TXT
B430AB5 Commit B: aggiunto B.TXT
6f30e95 commit a: aggiunto a.TXT
$ ls
UN.txt b.txt c.TXT

Risultati per "Funzione":

Funzione $ Git Checkout
Cambia alla funzione di ramo "
$ git log --oneline
0286690 commit f: modificato B.TXT
7c5c85e commit e: modificato a.TXT
B430AB5 Commit B: aggiunto B.TXT
6f30e95 commit a: aggiunto a.TXT
$ ls
UN.txt b.TXT

Notare come il ramo di funzionalità non ha commit c

Ora eseguiamo il ramo della funzione "Monge" con il ramo "Master". Ti verrà chiesto di inserire un commento. Nel commento, aggiungi "commit g:" all'inizio per semplificare la traccia.

$ git checkout master
Passato a Branch 'Master'
Funzione $ Git Merge
Unione fatta dalla strategia "ricorsiva".
UN.txt | 1 +
B.txt | 1 +
2 file modificati, 2 inserzioni (+)

Risultati per "Master":

$ git checkout master
Già su "Master"
$ git log --oneline
D086FF9 commit g: unione della funzione di filiale "
0286690 commit f: modificato B.TXT
7c5c85e commit e: modificato a.TXT
2BBDE47 commit c: aggiunto c.TXT
B430AB5 Commit B: aggiunto B.TXT
6f30e95 commit a: aggiunto a.TXT
$ ls
UN.txt b.txt c.TXT

Risultati per "Funzione":

Funzione $ Git Checkout
Cambia alla funzione di ramo "
$ git log --oneline
0286690 commit f: modificato B.TXT
7c5c85e commit e: modificato a.TXT
B430AB5 Commit B: aggiunto B.TXT
6f30e95 commit a: aggiunto a.TXT
$ ls
UN.txt b.TXT

Nel ramo "Master", noterai che esiste un nuovo commit che ha unito le modifiche alla filiale "Feature". Fondamentalmente, la seguente azione ha avuto luogo:

A - B - C - G (Master)
\ /
E - F (Feature)

Nel commit g, tutte le modifiche dalla filiale "caratteristica" sono state portate nel ramo principale. Ma la stessa filiale "caratteristica" è rimasta intatta a causa del processo di unione. Notare l'hash di ogni commit. Dopo la fusione, E (7C5C85E) e F (0286690) hanno lo stesso hash sul ramo "Feature" e "Master".

---

3. Unendo con il ribasso

Ripetiamo il passaggio 1 per creare di nuovo i rami "Master" e "Funzione".

Risultati per "Master":

$ git checkout master
Passato a Branch 'Master'
$ git log --oneline
7f573d8 commit c: aggiunto c.TXT
795DA3C Commit B: aggiunto B.TXT
0f4ed5b commit a: aggiunto a.TXT
$ ls
UN.txt b.txt c.TXT

Risultati per "Funzione":

Funzione $ Git Checkout
Cambia alla funzione di ramo "
$ git log --oneline
8ed0c4e commit f: modificato B.TXT
6e12b57 commit e: modificato a.TXT
795DA3C Commit B: aggiunto B.TXT
0f4ed5b commit a: aggiunto a.TXT
$ ls
UN.txt b.TXT

REBASE DALLA BRIMINA.

Funzione $ Git Checkout
Cambia alla funzione di ramo "
$ git rebase master
Innanzitutto, riavvolgendo la testa per riprodurre il tuo lavoro sopra ..
Applicazione: commit e: modificato a.TXT
Applicazione: commit f: modificato B.TXT

Quindi unisci "funzione" in "Master".

$ git checkout master
Passato a Branch 'Master'
Funzione $ Git Merge
Aggiornamento di 7f573d8… 9efa1a3
Avanti veloce
UN.txt | 1 +
B.txt | 1 +
2 file modificati, 2 inserzioni (+)

Risultati per il ramo "Master":

$ git checkout master
Già su "Master"
$ git log --oneline
9EFA1A3 commit f: modificato B.TXT
8710174 commit e: modificato a.TXT
7f573d8 commit c: aggiunto c.TXT
795DA3C Commit B: aggiunto B.TXT
0f4ed5b commit a: aggiunto a.TXT
$ ls
UN.txt b.txt c.TXT

Risultati per il ramo "Funzione":

Funzione $ Git Checkout
Cambia alla funzione di ramo "
$ git log --oneline
9EFA1A3 commit f: modificato B.TXT
8710174 commit e: modificato a.TXT
7f573d8 commit c: aggiunto c.TXT
795DA3C Commit B: aggiunto B.TXT
0f4ed5b commit a: aggiunto a.TXT
$ ls
UN.txt b.txt c.TXT

Si noti che dopo Rebase e unione entrambi i rami sono gli stessi. Inoltre, gli hash per E e F sono cambiati in entrambi i rami. Fondamentalmente, nello scenario Rebase, questo è quello che è successo:

A - B - C
\
E ' - f' (caratteristica, master)

Ecco perché non c'è nuovo commit. I commit E e F sono stati ricalcolati e bloccati alla fine del ramo "Master".

Il ribasso è uno strumento utile quando si desidera ripulire la storia del tuo lavoro. Tuttavia, esiste un pericolo che ha dato alla luce la regola d'oro.

---

Golden Regola di ribasersi

La regola d'oro del ribasso è:

Non ribella mai una filiale pubblica.

Come puoi vedere dall'esempio sopra, ribasciare ricalcola gli commit. Quando più persone si stanno ramificando da un repository pubblico, il ribasso può creare situazioni in cui gli sviluppatori che hanno creato nuovi filiali si imbatteranno in situazioni di unione molto complicate. Quindi, è una buona idea non ribellare le filiali pubbliche che sono condivise.

Insomma:

Rebasing è una caratteristica unica di Git. Ma usalo con cautela.

Maggiori informazioni:

Ecco alcuni link per ulteriori studi:

• Documentazione Git Rebase
• Atlassian Fleing vs Rebasing
• Come visualizzare la cronologia del commit del repository Git
• Mostra albero git nel terminale
• https: // www.Atlassian.com/git/tutorials/fusion-vs-rebasing
• https: // git-scm.com/docs/git-rebase