Rewriting history

Source code management

 

Source code management (SCM) is used to track modifications to a source code repository. SCM tracks a running history of changes to a code base and helps resolve conflicts when merging updates from multiple contributors. SCM is also synonymous with Version control. 

As software projects grow in lines of code and contributor head count, the costs of communication overhead and management complexity also grow. SCM is a critical tool to alleviate the organizational strain of growing development costs.

Introduction

Ce tutoriel aborde diverses méthodes de réécriture et de modification de l'historique Git. Git utilise plusieurs méthodes différentes pour enregistrer les changements. Nous aborderons les atouts et les faiblesses de chacune d'elles, et nous expliquerons comment les utiliser. Ce tutoriel développe certaines des raisons les plus courantes pour lesquelles les instantanés commités sont écrasés et vous explique comment éviter les pièges associés à cette opération.

La principale tâche de Git est de s'assurer que vous ne perdiez jamais un changement commité. Git est également conçu pour vous donner le contrôle total de votre workflow de développement. Il vous permet notamment de définir avec exactitude l'apparence de votre historique de projet, mais il crée également des conditions pouvant entraîner la perte de commits. Git fournit ses commandes de réécriture de l'historique en se dégageant de toute responsabilité en cas de perte de contenu découlant de leur utilisation.

Git comprend plusieurs mécanismes de stockage de l'historique et d'enregistrement des changements, parmi lesquels : commit --amend, git rebase et git reflog. Ces options permettent de personnaliser le workflow. À l'issue de ce tutoriel, vous maîtriserez des commandes qui vous permettront de restructurer vos commits Git et vous serez en mesure d'éviter les pièges courants lors de la réécriture de l'historique.

This foundational conflict prevention mechanism has the side effect of providing passive communication for the development team. The team can then monitor and discuss the work in progress that the SCM is monitoring. The SCM tracks an entire history of changes to the code base. This allows developers to examine and review edits that may have introduced bugs or regressions.

Ne pas modifier les commits publics

Les commits modifiés sont en réalité des commits entièrement nouveaux. Les anciens commits ne se trouveront plus dans votre branche actuelle. Les conséquences associées sont les mêmes que pour la réinitialisation d'un instantané public. Évitez de modifier un commit sur lequel repose le travail d'autres développeurs. Cette situation est déroutante, et il est difficile de revenir en arrière.

Pour modifier des commits plus anciens ou plusieurs commits, vous pouvez utiliser git rebase afin de combiner une séquence de commits dans un nouveau commit de base. Dans le mode standard, git rebase vous permet de réécrire l'historique, c'est-à-dire d'appliquer automatiquement des commits de votre branche de travail actuelle à l'élément HEAD de la branche transmise. Puisque vos nouveaux commits vont remplacer les anciens, il est important de ne pas utiliser git rebase sur des commits publics. Sinon, votre historique de projet disparaîtra.

Lorsqu'il est important de conserver un historique de projet propre, vous pouvez ajouter l'option -i à la commande git rebase pour exécuter un rebase interactif. Vous avez ainsi la possibilité de modifier des commits individuels du processus plutôt que de déplacer tous les commits. Pour de plus amples informations sur le rebase interactif et des commandes rebase supplémentaires, reportez-vous à la page git rebase.

Durant un rebase, la commande edit ou e interrompt la lecture du rebase à ce commit, ce qui vous permet d'apporter des changements supplémentaires avec git commit --amend. Git interrompt la lecture et affiche le message suivant :

Messages multiples

Squasher des commits pour nettoyer l'historique

Notez que les commits modifiés à l'aide d'une commande rebase possèdent un ID différent des commits d'origine. Les commits marqués d'une coche recevront un nouvel ID si les commits précédents ont été réécrits.

Récapitulatif

git rebase vous donne la possibilité de modifier votre historique, alors que le rebase interactif vous permet de le faire sans laisser de traces. Vous avez ainsi la liberté de faire des erreurs, de les corriger et d'affiner votre travail tout en conservant un historique de projet propre et linéaire.

Le filet de sécurité : git reflog

Les journaux de référence ou reflogs constituent un mécanisme utilisé par Git pour enregistrer les mises à jour appliquées aux pointes des branches et à d'autres références de commit. Le reflog vous permet de revenir sur les commits même s'ils ne sont pas référencés par une branche ou un tag. Une fois l'historique réécrit, le reflog contient des informations sur l'ancien état des branches et vous permet d'y revenir si nécessaire. À chaque mise à jour de la pointe de votre branche quelle qu'en soit la raison (en changeant de branche, en faisant un pull de nouveaux changements, en réécrivant l'historique ou simplement en ajoutant de nouveaux commits), une nouvelle entrée est ajoutée au reflog. Dans cette section, nous verrons brièvement la commande git reflog et nous étudierons quelques cas d'usage courants.

Utilisation

Cette commande affiche le reflog pour le dépôt local.

Exemple

Pour comprendre git reflog, nous allons étudier un exemple concret.

Agree on a Workflow

By default SCMs offer very free form methods of contribution. It is important that teams establish shared patterns of collaboration. SCM workflows establish patterns and processes for merging branches. If a team doesn't agree on a shared workflow it can lead to inefficient communication overhead when it comes time to merge branches.

Résumé

Dans cet article, nous avons vu plusieurs méthodes pour modifier l'historique et annuler des changements dans Git. Nous avons étudié le processus git rebase dans les grandes lignes. Voici les enseignements clés de ce module :

  • Vous disposez de plusieurs méthodes pour réécrire l'historique avec Git.
  • Utilisez git commit --amend pour modifier votre dernier message de log.
  • Utilisez git commit --amend pour apporter des changements au dernier commit.
  • Utilisez git rebase pour combiner des commits et modifier l'historique d'une branche.
  • À l'inverse d'une commande git rebase standard, git rebase -i vous offre un contrôle plus fin sur les changements apportés à l'historique.