Discussion :

[ikane]

Bonjour,

Je suis nouveau sur GIT.

Quelqu'un pourrait-il m'expliquer succinctement ce que fait "git rebase" et quand l'utiliser?

Merci

[Marco46]

La fonction rebase de git permet de réécrire l'historique d'une branche.

On l'utilise pour mettre à jour une branche locale que l'on a pas encore mergé avec la branche principale (master généralement sur les repo git) afin d'obtenir un merge fast forward.

Par exemple.

J'ai ma branche principale nommée master qui est dans cet état au moment où je vais créer ma branche locale (sur laquelle je vais dev ma feature et que je vais nommer par exemple toto) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3

Je crée une branche toto qui démarre donc au commit M3.

J'écris les modifs (constituées pour l'exemple de 2 commits T1 et T2) pour ma feature toto dans ma branche toto, mon historique pour cette branche est donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3 - T1 - T2

Entre temps un collège a mergé sa branche zozo dans master. Master est donc dans cet état :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3 - Z1 - Z2 - Z3

Après avoir mis à jour mon master local, mon tree est donc dans cet état :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
M1 - M2 - M3 - Z1 - Z2 - Z3
           \ 
           T1 - T2

A ce stade 2 solutions, soit je fais un git merge toto dans develop, soit je rebase d'abord ma branche toto.

Si je fais un merge j'obtiens ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
M1 - M2 - M3 - Z1 - Z2 - Z3 - M4
           \                 /
           T1 - T2 ----------

Où M4 est un commit de merge. Git aura été obligé de faire un merge non-fast-forward.

Maintenant si je rebase ma branche locale toto :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
M1 - M2 - M3 - Z1 - Z2 - Z3
                          \  
                          T1 - T2

L'opération a changé le parent de T1. Le parent de T1 était M3 avant le rebase, après le rebase c'est Z3.

Je peux alors faire un merge qui sera fast-forward et j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3 - Z1 - Z2 - Z3 - T1 - T2

Je n'ai plus qu'à pousser mon master sur le repo central.



Voilà, je peux pas expliquer mieux que ça !

[Marco46]

Bon la mise en page dans les balises CODE déconne à plein régime.

Cf mes notes sur mon github pour avoir une vue plus claire.

[ikane]

La fonction rebase de git permet de réécrire l'historique d'une branche.

On l'utilise pour mettre à jour une branche locale que l'on a pas encore mergé avec la branche principale (master généralement sur les repo git) afin d'obtenir un merge fast forward.

Par exemple.

J'ai ma branche principale nommée master qui est dans cet état au moment où je vais créer ma branche locale (sur laquelle je vais dev ma feature et que je vais nommer par exemple toto) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3

Je crée une branche toto qui démarre donc au commit M3.

J'écris les modifs (constituées pour l'exemple de 2 commits T1 et T2) pour ma feature toto dans ma branche toto, mon historique pour cette branche est donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3 - T1 - T2

Entre temps un collège a mergé sa branche zozo dans master. Master est donc dans cet état :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3 - Z1 - Z2 - Z3

Après avoir mis à jour mon master local, mon tree est donc dans cet état :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
M1 - M2 - M3 - Z1 - Z2 - Z3
           \ 
           T1 - T2

A ce stade 2 solutions, soit je fais un git merge toto dans develop, soit je rebase d'abord ma branche toto.

Si je fais un merge j'obtiens ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
M1 - M2 - M3 - Z1 - Z2 - Z3 - M4
           \                 /
           T1 - T2 ----------

Où M4 est un commit de merge. Git aura été obligé de faire un merge non-fast-forward.

Maintenant si je rebase ma branche locale toto :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
M1 - M2 - M3 - Z1 - Z2 - Z3
                          \  
                          T1 - T2

L'opération a changé le parent de T1. Le parent de T1 était M3 avant le rebase, après le rebase c'est Z3.

Je peux alors faire un merge qui sera fast-forward et j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
M1 - M2 - M3 - Z1 - Z2 - Z3 - T1 - T2

Je n'ai plus qu'à pousser mon master sur le repo central.



Voilà, je peux pas expliquer mieux que ça !

WAW! Grand merci Marco! C'est limpide!

Quelles sont les recommendations sur qd utiliser merge à la place de rebase ou vice-versa.

Encore merci!

[Marco46]

Ne jamais rebaser une branche qui est publique.

En d'autres termes, tu peux rebaser une branche tant que ya que toi qui la possède. A partir du moment où elle a été poussée sur ton repo central il ne faut plus le faire sinon tu vas réécrire l'historique public et ça va foutre le bordel dans le tree de tous tes collègues.

La bonne pratique c'est donc de rebaser systématiquement ta branche de feature avec la branche d'intégration des développements avant de pousser ta branche de feature pour effectuer une merge / pull request. Si les merges dans master/develop sont effectués en local par les devs c'est pareil, on rebase d'abord la branche de feature, puis on merge, puis on pousse master/develop. Ca permet d'obtenir un historique parfaitement linéaire qui est donc beaucoup plus facile à lire.

[ikane]

Ne jamais rebaser une branche qui est publique.

En d'autres termes, tu peux rebaser une branche tant que ya que toi qui la possède. A partir du moment où elle a été poussée sur ton repo central il ne faut plus le faire sinon tu vas réécrire l'historique public et ça va foutre le bordel dans le tree de tous tes collègues.

La bonne pratique c'est donc de rebaser systématiquement ta branche de feature avec la branche d'intégration des développements avant de pousser ta branche de feature pour effectuer une merge / pull request. Si les merges dans master/develop sont effectués en local par les devs c'est pareil, on rebase d'abord la branche de feature, puis on merge, puis on pousse master/develop. Ca permet d'obtenir un historique parfaitement linéaire qui est donc beaucoup plus facile à lire.

MErci encore!