Articles

Cos’è una cronologia git lineare

Se sei mai stato nell’installazione del ramo protetto di Github, probabilmente l’hai visto attraverso questa impostazione.

 github-impostazioni.png

Devi chiedermi di cosa si tratta. In effetti, la maggior parte del flusso di lavoro di git lo scoraggia, quindi nessuno dovrebbe prestare attenzione ad esso. Ma l’ho visto comunque, quindi scopriamolo.

Define

A mio parere, è semplicemente una cronologia di commit senza un commit di unione. Significa che ogni commit ha solo 1 genitore e 1 figlio. Sembrerà una linea retta.

Per esempio come questo

1
2

—o—o—o—o—o

E questa non è una storia lineare

1
2
3
4

—o—o—o—M—o—o
/
—x—x

Come ottenere un lineare della storia

Prima di tutto, quando abbiamo il commit di unione. Il commit di unione viene generato quando uniamo 2 rami ma non è possibile utilizzare la strategia fast forward, git creerà un commit di unione per unire 2 rami. Ad esempio abbiamo 2 rami come questo.

1
2
3
4

master —o—o—o
test A—B

Quando testing sta avendo la stessa storia, come il master , con solo 2 commit A e B , siamo in grado di fast forward . Significa che basta applicare le modifiche di A e B è fatto.

1
2

master —o—o—o—A—B

Ma se ci sono 2 rami come questo.

1
2
3
4

master —o—o—o—C—D
test A—B

Allora non sarà in grado di utilizzare in avanti, è necessario creare una unione di commit. Unisci il ramo 2 sarà simile a questo.

1
2
3
4

master —o—o—o—C—D—M
/
il test di Un——-B

Se si utilizza git merge con il --no-ff bandiera, anche se il ramo può essere veloce in avanti , un unione di commettere ancora essere creato.

1
2
3
4

master —o—o—o——-M—
/
prova A—B

Quindi, per ottenere un lineare della storia, abbiamo bisogno di assicurarsi che ogni unione e ramo fusione deve avere un up-to-data la storia con la base del ramo in modo da poter usare il fast forward strategia. Per aggiornare il ramo con il ramo base, usiamo git rebase. Rebase riapplicherà tutti i commit del ramo corrente al ramo base.

L’esempio di ramo corrente è questo. Ramo feature controllato dal master a commettere A

1
2
3
4

master —A—B—C
funzione D—E

Se si uniscono i 2 rami ora, si viene a creare una unione di commit. Ora dal ramo feature uso git rebase in questo modo.

1
2

git rebase master

Sarà come il feature sarà controllato di nuovo da commit C , quindi eseguire il commit D e E potranno essere ri-applicato a feature . Ora branch sarà simile a questo.

1
2
3
4

master —A—B—C
funzione D—E

Il feature ora possono essere uniti nel master con il fast forward strategia.

Nota che rebase cambierà la cronologia come vedi sopra. Quindi usi solo rebase sul ramo corrente che stai facendo (non spinto al repository generale) solo. Se lavori con una funzionalità ampia e dispendiosa in termini di tempo (lavorando da solo, non condividere un ramo con nessuno), il rebasing regolare con il ramo di base aiuterà l’aggiornamento del codice con l’ultimo codice dal ramo di base ed è ora di unire. conflitto di funzionalità e bug non ancora scoperti.

Storia lineare per cosa

Quindi perché le persone vogliono una storia lineare. Ci sono diversi vantaggi come segue

  • Determinare facilmente l’ordine dei commit. Probabilmente sai già che i commit di merge combinano effettivamente due rami e ogni ramo può avere una storia indipendente l’uno dall’altro. Quando si utilizza git log, si vede che i commit sono organizzati come una linea retta. Ma in realtà è così facile da leggere. E in realtà sembra l’immagine qui sopra. Quindi è difficile determinare quale sia il primo, ed è difficile sapere quale commit abbia effettivamente causato un errore.
  • Commit storia più pulito. Non ci saranno commit di fusione che ti confonderanno più. E provi a eseguire git log --graph con un repository senza una cronologia lineare, lo capirai.
  • Ripristina facilmente il commit. Poiché ogni commit ha solo 1 genitore, a differenza di merge commit, revert commit o cherry-picks è molto meno mal di testa.

Difetto:

  • Hai bisogno di utenti per capire git. git rebase in realtà abbastanza difficile da usare e fa un errore di cronologia di commit facilmente.
  • Correggi il conflitto con git rebase molto più difficile di git merge . Con merge, abbiamo solo bisogno di risolvere il conflitto in un commit. Mentre con rebase, forse ogni commit ha un conflitto.
  • In realtà, potrebbe non essere necessario una bella storia. Tutti stanno bene con git merge.

Richiede cronologia lineare su Github

Se questa funzione è abilitata su Github, non sarà più possibile unire le richieste di pull creando commit di unione.

 github-merge-linear.png

Hai solo 2 opzioni a sinistra: Squash e unisci e Rebase e unisci . Squash and merge schiaccerà tutti i commit nelle richieste di pull, rebase e merge. Rebase e merge è quasi il rebase che vediamo sopra. Entrambi utilizzano la strategia fast forward in modo da non creare commit di unione aggiuntivi e mantenere lineare la cronologia dei commit.

Se ti unisci a Rebase e unisci, quando torni a PR, Github renderà ogni commit in PR un commit di ripristino invece di un solo commit grande come il commit di unione.

 github-revert-rebase.png

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.