Rebasage et que veut-on dire par rebasage des commits poussés

On dit souvent que vous ne devez 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 précise à votre question se trouve dans la section intitulée « Les dangers de la réinstallation ». Une citation de cette section:

Lorsque vous rebasez des éléments, vous abandonnez les commits existants et en créez de nouveaux qui sont similaires mais différents. Si vous poussez des commits quelque part et que d'autres les tirent vers le bas et basent leur travail sur eux, puis vous réécrivez ces commits avec git rebase et les poussez à nouveau, vos collaborateurs devront fusionner à nouveau leur travail et les choses deviendront compliquées lorsque vous essayez de ramenez leur travail dans le vôtre.

Mise à jour: d'
après votre commentaire ci-dessous, il semble que vous rencontriez des difficultés avec votre flux de travail Git. Voici quelques références qui peuvent vous aider:

• La gitworkflowspage de manuel: voir "Fusion vers le haut" et "Branches de rubrique"
• ProGit: voir " Équipe gérée privée "
• Blog de Jarrod Spillers: voir " git merge vs git rebase: éviter l'enfer de rebase "

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

il a quatre commits sur la branche principale, et chaque commit a un ID (dans ce cas, a, b, c et d). Vous remarquerez que d est actuellement le dernier commit (ou HEAD) de la branche master.

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

Alors disons que my-branch est devenu obsolète, et que vous voulez le mettre à jour avec la dernière version de master. Pour le dire autrement, my-branch doit contenir c et d. Vous pouvez faire une fusion, mais cela fait que la branche contient des commits de fusion étranges qui rendent l'examen de la demande d'extraction beaucoup plus difficile. Au lieu de cela, vous pouvez effectuer un rebase.

Quand vous rebase, git trouve la base de votre branche (dans ce cas, b), trouve tous les commits entre cette base et HEAD (dans ce cas, e et f), et rejoue ces commits sur le HEAD de la branche vous rebasez sur (dans ce cas, maître). Git crée en fait de nouveaux commits qui représentent à quoi ressemblent vos changements par-dessus 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 façon dont les choses étaient auparavant.

Lorsque de nombreuses personnes différentes travaillent sur un projet de manière simulée, les demandes d'extraction peuvent rapidement devenir obsolètes. Une pull request "obsolète" est une requête qui n'est plus à jour avec la ligne principale de développement et qui doit être mise à jour avant de pouvoir être fusionnée dans le projet. La raison la plus courante pour laquelle les demandes d'extraction deviennent obsolètes est due à des conflits: si deux demandes d'extraction modifient toutes les deux des lignes similaires dans le même fichier et qu'une demande d'extraction est fusionnée, la demande d'extraction non fusionnée aura désormais un conflit. Parfois, une pull request peut devenir obsolète sans conflits: peut-être que les changements dans un fichier différent dans la base de code nécessitent des changements correspondants dans votre pull request pour se conformer à la nouvelle architecture, ou peut-être que la branche a été créée quand quelqu'un a accidentellement fusionné des tests unitaires échouants avec le branche principale. Quelle que soit la raison,

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

Les complots sont vraiment difficiles à maintenir ensemble, il vaut donc mieux éviter de rebaser les branches publiques en premier lieu.

Notez qu'il existe des exemples de conspirations réussies: la pubranche du dépôt git de Junio ​​C. Hamano (le dépôt officiel du Git SCM) est fréquemment rebasée. La façon dont cela fonctionne est que presque tous ceux qui utilisent pusont également abonnés à la liste de diffusion des développeurs Git, et le fait que la pubranche soit rebasée est largement diffusé sur la liste de diffusion et sur le site Web de Git.

Un rebase modifie l'historique de votre référentiel. Si vous transférez les commits vers le monde, c'est-à-dire que vous les rendez disponibles à d'autres, et que vous changez ensuite votre vision de l'historique des commits, il devient difficile de travailler avec quelqu'un qui a votre ancienne histoire.

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