Rebasing et que signifie-t-on en rebasant les commits

On dit souvent que, vous ne devriez pas rebaser les commits que vous avez déjà poussés. Quelle pourrait être la signification de cela?

Le livre ProGit a une bonne explication .

La réponse spécifique à votre question peut être trouvée dans la section intitulée ” Les dangers du changement de base “. Une citation de cette section:

Lorsque vous rebassez des éléments, vous abandonnez les commits existants et en créez de nouveaux similaires mais différents. Si vous poussez des commits quelque part et que d’autres les réduisent et que vous les travaillez, puis que vous réécrivez ces validations avec git rebase et que vous les relancez, vos collaborateurs vont devoir recomposer leur travail et les choses se gâteront ramenez leur travail dans le vôtre.

Mettre à jour:
Sur la base de votre commentaire ci-dessous, il semble que vous ayez des difficultés avec votre stream de production Git. Voici quelques références qui peuvent aider:

  • La page de manuel gitworkflows : voir “Fusion vers le haut” et “Branches de sujet”
  • ProGit: Voir ” Équipe gérée privée ”
  • Blog de Jarrod Spillers: Voir ” Git merge vs git rebase: Eviter Rebase Hell ”

Pour comprendre cela, nous devons comprendre un peu comment fonctionne git. Un référentiel git est une arborescence, où les nœuds de l’arbre sont validés. Voici un exemple de référentiel très simple: Quand vous fourchez

il a quatre commits sur la twig master et chaque commit a un identifiant (dans ce cas, a, b, c et d). Vous remarquerez que d est actuellement le dernier commit (ou HEAD) de la twig master. entrer la description de l'image ici

Ici, nous avons deux twigs: maître et ma twig. Vous pouvez voir que master et my-branch contiennent tous deux des commits a et b, mais ils commencent alors à diverger: master contient c et d, alors que ma twig contient e et f. b est dit être la “base de fusion” de ma twig par rapport à la base – ou plus communément, juste la “base”. Cela a du sens: vous pouvez voir que ma twig était basée sur une version précédente de master.

Alors, disons que ma twig est devenue obsolète et que vous voulez la mettre à jour avec la dernière version de master. En d’autres termes, ma twig doit contenir c et d. Vous pourriez faire une fusion, mais la twig contiendrait des commits de fusion bizarres, ce qui compliquerait l’examen de la requête d’extension. Au lieu de cela, vous pouvez faire un rebase.

entrer la description de l'image ici

Lorsque vous rebase, git trouve la base de votre twig (dans ce cas, b), trouve tous les commits entre cette base et HEAD (dans ce cas, e et f), et rejoue ces validations sur le HEAD de la twig. vous repasse sur (dans ce cas, maître). Git crée en fait de nouveaux commits qui représentent ce à quoi ressemblent vos changements au-dessus de master: dans le diagramme, ces commits sont appelés e et f. Git n’efface pas vos commits précédents: e et f ne sont pas modifiés, et si quelque chose ne va pas avec le rebase, vous pouvez revenir à la configuration habituelle.

Lorsque de nombreuses personnes travaillent sur un projet de manière simulée, les demandes d’extraction peuvent devenir rapidement obsolètes. Une demande d’extraction “périmée” n’est plus à jour avec la ligne de développement principale et doit être mise à jour avant de pouvoir être intégrée au projet. La raison la plus courante pour laquelle les requêtes d’extraction deviennent obsolètes est due à des conflits: si deux requêtes à la fois modifient des lignes similaires dans le même fichier et qu’une requête d’extraction est fusionnée, la requête d’extraction non fusionnée est désormais en conflit. Parfois, une requête d’extraction peut devenir périmée sans conflits: peut-être que les modifications dans un fichier différent dans la base de code nécessitent des modifications correspondantes dans votre demande d’extraction pour se conformer à la nouvelle architecture. twig principale. Quelle que soit la raison, si votre demande d’extraction est devenue obsolète, vous devrez redéfinir votre twig sur la dernière version de la twig principale avant de pouvoir la fusionner.

Rebasing réécrit l’histoire. Si personne ne connaît cette histoire, alors c’est parfaitement bien. Si, cependant, cette histoire est connue du public, alors la réécriture de l’histoire dans Git fonctionne exactement comme elle le fait dans le monde réel: vous avez besoin d’un complot.

Les conspirations sont vraiment difficiles à garder ensemble, alors il vaut mieux éviter de rebaser les twigs publiques en premier lieu.

Notez qu’il existe des exemples de conspirations réussies: la twig pu du repository git de Junio ​​C. Hamano (le repository officiel du Git SCM) est fréquemment rebasée. La façon dont cela fonctionne est que quasiment tous les utilisateurs de pu sont également abonnés à la liste de diffusion des développeurs Git, et le fait que la twig pu soit rebasée est largement diffusé sur la liste de diffusion et sur le site Web de Git.

Une rebase modifie l’historique de votre référentiel. Si vous poussez des commits vers le monde, c’est-à-dire les mettre à la disposition des autres, et que vous modifiez ensuite votre vision de l’historique des validations, il devient difficile de travailler avec quiconque possède votre ancien passé.

Rebase considéré comme dangereux est un bon aperçu, je pense.