IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

Explication git rebase


Sujet :

ALM

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    41
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 41
    Points : 30
    Points
    30
    Par défaut Explication git rebase
    Bonjour,

    Je suis nouveau sur GIT.

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

    Merci

  2. #2
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    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) :

    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 !
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  3. #3
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    41
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 41
    Points : 30
    Points
    30
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    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) :

    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!

  5. #5
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  6. #6
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    41
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 41
    Points : 30
    Points
    30
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    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!

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Foreign Key] Besoin d'explication.
    Par Andry dans le forum Débuter
    Réponses: 4
    Dernier message: 28/05/2003, 12h34
  2. pointeurs (explications)
    Par isidore dans le forum C
    Réponses: 4
    Dernier message: 18/04/2003, 11h41
  3. Explication procédure stockée
    Par underworld dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 09/09/2002, 11h51
  4. Recherche code d'un fifo,ou explication
    Par don-diego dans le forum C
    Réponses: 8
    Dernier message: 25/07/2002, 11h26
  5. recherches des cours ou des explications sur les algorithmes
    Par Marcus2211 dans le forum Algorithmes et structures de données
    Réponses: 6
    Dernier message: 19/05/2002, 23h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo