le rebasage est le processus de déplacement ou de combinaison d’une séquence de commits vers un nouveau commit de base. Le rebasage est très utile et facilement visualisé dans le contexte d’un workflow de branchement de fonctionnalités. Le processus général peut être visualisé comme suit:

du point de vue du contenu, le rebasage modifie la base de votre branche d’un commit à un autre, ce qui donne l’impression que vous avez créé votre branche à partir d’un commit différent., En interne, Git accomplit cela en créant de nouveaux commits et en les appliquant à la base spécifiée. Il est très important de comprendre que même si la branche se ressemble, elle est composée de commits entièrement nouveaux.

utilisation

La principale raison du rebasage est de maintenir un historique de projet linéaire. Par exemple, considérez une situation où la branche principale a progressé depuis que vous avez commencé à travailler sur une branche de fonctionnalité., Vous souhaitez obtenir les dernières mises à jour de la branche principale dans votre branche de fonctionnalité, mais vous souhaitez garder l’historique de votre branche propre afin qu’il apparaisse comme si vous travailliez sur la dernière branche principale. Cela donne l’avantage ultérieur d’une fusion propre de votre branche d’entités dans la branche principale. Pourquoi voulons-nous maintenir une « nouvelle histoire »? Les avantages d’avoir un historique propre deviennent tangibles lors de l’exécution D’opérations Git pour étudier l’introduction d’une régression. Un scénario plus réel serait:

1. Un bogue est identifié dans la branche master., Une fonctionnalité qui fonctionnait avec succès est maintenant cassée.
2. Un développeur examine l’historique de la branche principale en utilisant git log en raison de l ‘ « historique propre », le développeur est rapidement en mesure de raisonner sur l’historique du projet.
3. Le développeur ne peut pas identifier quand le bogue a été introduit en utilisant git logdonc le développeur exécute un git bisect.
4. parce que l’historique git est propre,git bisect a un ensemble raffiné de commits à comparer lors de la recherche de la régression., Le développeur trouve rapidement le commit qui a introduit le bogue et est capable d’agir en conséquence.

en savoir plus sur git log et git bisect sur leurs pages d’utilisation individuelles.

Vous avez deux options pour intégrer votre fonctionnalité dans la branche master: fusionner directement ou rebaser puis fusionner. La première option se traduit par une fusion à 3 voies et un commit de fusion, tandis que la seconde se traduit par une fusion rapide et un historique parfaitement linéaire. Le diagramme suivant montre comment le rebasage sur la branche principale facilite une fusion rapide.,

le rebasage est un moyen courant d’intégrer les modifications en amont dans votre référentiel local. L’ajout de modifications en amont avec git merge entraîne un commit de fusion superflu chaque fois que vous souhaitez voir comment le projet a progressé. D’un autre côté, le rebasage revient à dire: « je veux baser mes changements sur ce que tout le monde a déjà fait. »

ne rebase pas l’historique public

Comme nous l’avons vu précédemment dans réécrire l’historique, vous ne devriez jamais rebaser les commits une fois qu’ils ont été poussés vers un dépôt public., Le rebase remplacerait les anciens commits par de nouveaux et il semblerait que cette partie de l’histoire de votre projet ait brusquement disparu.

Git Rebase Standard vs Git Rebase Interactif

Git rebase interactif est quand git rebase accepte un -- i argument. Ceci représente « Interactif. »Sans argument, la commande s’exécute en mode standard. Dans les deux cas, supposons que nous ayons créé une branche de fonctionnalité distincte.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase en mode standard prendra automatiquement les commits dans votre branche de travail actuelle et les appliquera à l’en-tête de la branche passée.

 git rebase 

cela rebase automatiquement la branche actuelle sur, qui peut être n’importe quel type de référence de validation (par exemple un ID, un nom de branche, une balise ou une référence relative àHEAD).

L’exécution degit rebase avec l’indicateur-i commence une session de rebasage interactive., Au lieu de déplacer aveuglément tous les commits vers la nouvelle base, le rebasage interactif vous donne la possibilité de modifier les commits individuels dans le processus. Cela vous permet de nettoyer l’historique en supprimant, fractionnant et modifiant une série de commits existante. C’est comme Git commit --amend sur les stéroïdes.

 git rebase --interactive 

cela rebase la branche actuelle sur mais utilise une session de rebasage interactive. Cela ouvre un éditeur où vous pouvez entrer des commandes (décrites ci-dessous) pour chaque commit à rebaser., Ces commandes déterminent comment les commits individuels seront transférés vers la nouvelle base. Vous pouvez également réorganiser la liste des commits pour modifier l’ordre des commits eux-mêmes. Une fois que vous avez spécifié des commandes pour chaque commit dans le rebase, Git commencera à lire les commits en appliquant les commandes rebase. Les commandes d’édition de rebasage sont les suivantes:

commandes de rebasage supplémentaires

comme détaillé dans la page historique de réécriture, le rebasage peut être utilisé pour modifier des commits plus anciens et multiples, des fichiers validés et plusieurs messages., Bien que ce soient les applications les plus courantes, git rebase dispose également d’options de commande supplémentaires qui peuvent être utiles dans des applications plus complexes.

• git rebase -- d signifie que pendant la lecture, la validation sera supprimée du bloc de validation combiné final.
• git rebase -- p feuilles de la commettre est. Il ne modifiera pas le message ou le contenu du commit et sera toujours un commit individuel dans l’historique des branches.
• git rebase -- x pendant la lecture exécute un script shell de ligne de commande sur chaque commit marqué., Un exemple utile serait d’exécuter la suite de tests de votre base de code sur des commits spécifiques, ce qui peut aider à identifier les régressions lors d’un rebase.

Récapitulatif

Interactif complet vous donne un contrôle complet sur votre projet histoire ressemble. Cela offre beaucoup de liberté aux développeurs, car cela leur permet de commettre un historique « désordonné » pendant qu’ils se concentrent sur l’écriture de code, puis de revenir en arrière et de le nettoyer après coup.

la plupart des développeurs aiment utiliser un rebase interactif pour polir une branche de fonctionnalité avant de la fusionner dans la base de code principale., Cela leur donne la possibilité d’écraser les commits insignifiants, de supprimer les commits obsolètes et de s’assurer que tout le reste est en ordre avant de s’engager dans l’historique « officiel” du projet. Pour tout le monde, il semblera que toute la fonctionnalité a été développée en une seule série de commits bien planifiés.

Le pouvoir réel du rebasing interactif peut être vu dans l’histoire de la branche master qui en résulte. Pour tout le monde, il semble que vous soyez un développeur brillant qui a implémenté la nouvelle fonctionnalité avec le nombre parfait de commits la première fois., C’est ainsi que le rebasage interactif peut garder l’historique d’un projet propre et significatif.

Options de Configuration

Il existe quelques propriétés de rebase qui peuvent être définies à l’aide degit config. Ces options modifieront l’apparence de la sortie git rebase.

• rebase.stat: Un booléen qui est à false par défaut. L’option bascule l’affichage du contenu visuel diffstat qui montre ce qui a changé depuis la dernière dégradation.

• rebase.autoSquash: valeur booléenne qui permet d’activer la balise --autosquash le comportement.,

• rebase.missingCommitsCheck: peut être défini sur plusieurs valeurs qui modifient le comportement de rebase autour des commits manquants.,/tr>

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Lorsque dans git rebase --onto mode la commande étend à:

    git rebase --onto 

  Le --onto commande permet une forme plus puissante ou rebase qui permet de passer spécifique refs être les conseils d’un rebase.
  disons que nous avons un exemple de repo avec des branches comme:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB est basé sur featureA, cependant, nous réalisons que featureB ne dépend d’aucun des changements dans featureA et pourrait simplement être ramifié hors master.

    git rebase --onto master featureA featureB 

  featureA est la balise ., master devient et featureB est la référence pour ce HEAD de la pointeront à. Les résultats sont alors:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  comprendre les dangers de rebase

  Une mise en garde à prendre en compte lorsque vous travaillez avec git Rebase est que les conflits de fusion peuvent devenir plus fréquents pendant un flux de travail de rebase. Cela se produit si vous avez une branche de longue durée qui s’est éloignée de master., Finalement, vous voudrez rebaser contre master et à ce moment-là, il peut contenir de nombreux nouveaux commits avec lesquels vos changements de branche peuvent entrer en conflit. Ceci est facilement résolu en rebasant votre branche fréquemment contre master et en effectuant des commits plus fréquents. Les arguments de ligne de commande --continue Et --abort peuvent être passés à git rebase pour avancer ou réinitialiser le rebase en cas de conflit.

  Une mise en garde de rebase plus sérieuse est perdue commits de réécriture de l’histoire interactive., Exécuter rebase en mode interactif et exécuter des sous-commandes comme squash ou drop supprimera les commits du journal immédiat de votre branche. À première vue, cela peut apparaître comme si les commits avaient définitivement disparu. En utilisant git reflog ces commits peuvent être restaurés et le rebase entier peut être annulé. Pour plus d’informations sur l’utilisation de git reflog pour trouver des commits perdus, visitez notre page de documentation git reflog.

  git Rebase lui-même n’est pas sérieusement dangereux., Les cas de danger réel surviennent lors de l’exécution de la réécriture de l’historique des rebases interactives et de la force de pousser les résultats vers une branche distante partagée par d’autres utilisateurs. C’est un modèle qui devrait être évité car il a la capacité d’écraser le travail d’autres utilisateurs distants lorsqu’ils tirent.

  récupération de rebase en amont

  Si un autre utilisateur a rebasé et poussé de force vers la branche à laquelle vous vous engagez, ungit pull écrasera alors tous les commits que vous avez basés sur cette branche précédente avec la pointe qui a été poussée de force., Heureusement, en utilisant git reflog, vous pouvez obtenir le reflog de la branche distante. Sur le reflog de la branche distante, vous pouvez trouver une référence avant qu’elle ne soit rebasée. Vous pouvez ensuite rebaser votre branche par rapport à cette référence distante en utilisant l’option --onto comme indiqué ci-dessus dans la section Application de Rebase Avancée.

  Résumé

  Dans cet article, nous avons couvert git rebase utilisation. Nous avons discuté de cas d’utilisation de base et avancés et d’exemples plus avancés., Certains des principaux points de discussion sont:

  • git rebase standard vs modes interactifs
  • git rebase options de configuration
  • git rebase –sur
  • git rebase perdu commet