Fusionner ou rebaser : choisissez avec un graphique

• Commencez la fusion et le rebase à partir de copies identiques afin que la comparaison soit équitable.
• Lisez les deux parents d'un commit de fusion et le nouveau parent unique d'un commit rebasé.
• Expliquez pourquoi deux copies peuvent se terminer par les mêmes fichiers tout en ayant des historiques différents.
• Choisissez avec une seule règle : réécrivez uniquement les commits que personne d’autre n’a.

Vous avez besoin de deux copies distinctes de la divergence de la leçon 20, nommées gittree-merge et gittree-rebase. Dans chaque copie, la branche feature/signup-form contient un de vos commits (appelez-le S), la branche updated-main contient un commit différent (appelez-le N), toutes deux démarrées à partir du même commit M et rescue/signup-before-rebase pointe sur S. La branche thématique est extraite et l'arborescence de travail est propre. Ne faites pas la deuxième copie à partir du résultat de la première.

Tout ici est local et sur le forfait gratuit (GitTree vous demande de vous connecter) : pas de compte d'hébergement, pas de fournisseur, pas d'Internet. Chaque identité est fictive (exemple.com) et vous ne devriez jamais exécuter cette leçon dans le cadre d'un projet réel.

Apportez les modifications dans GitTree ou avec les commandes Git natives, pas les deux dans la même copie. La lecture du résultat par la suite est toujours sûre. Les étiquettes de menu proviennent des propres chaînes de GitTree 2.0 ; les commandes natives ont été exécutées avec Git 2.43 dans des copies jetables. Les étapes GitTree n'ont pas été exécutées sur macOS, Windows ou Linux ; les raccourcis de l'application utilisent Command sur macOS où cette page écrit Ctrl.

Une comparaison n'est juste que lorsque les deux copies partent des mêmes références et des mêmes fichiers. Si vous fusionnez d'abord puis rebasez ce résultat, vous posez une question différente : la rediffusion a désormais une validation de fusion dans sa plage.

Merge conserve les deux secteurs d'activité. Il ajoute un nouveau commit, K, avec deux parents : S d'abord, puis N. S et N conservent leurs identifiants.

Rebase rejoue votre commit au-dessus de N. Le résultat, S′, a le même changement que S mais un nouveau parent, et l'ID d'un commit inclut son parent, donc S′ a un nouvel ID. L'ancien S ne survit que parce que la branche de sauvetage le pointe toujours.

Lorsqu'il n'y a aucun conflit, les deux copies se terminent par la même arborescence de fichiers. Des arbres égaux ne signifient pas une histoire égale : un graphique conserve un losange, l'autre une ligne droite et les ID de validation diffèrent.

La raison n’est pas une question de goût. Si d'autres personnes ont déjà vos commits, les rejouer brise leurs copies, alors fusionnez. Si les commits sont privés, un rebase est sûr et donne un historique linéaire si votre équipe en préfère un. Ni l’un ni l’autre n’améliore le code.

Dans chaque copie, seule la branche thématique bouge. Le serveur, updated-main et le principal d'origine ne sont pas touchés.

Faites une divergence, puis copiez-la deux fois. Commencez à partir d’une copie ordinaire distincte du projet telle que la leçon 18 l’a laissé (la principale est le commit de fusion M). Laissez votre gittree-features d'origine intact et ne l'exécutez jamais lors d'une extraction de source. L'identité de la démo est GitTree Demo, demo@example.com, avec la signature désactivée dans ce référentiel uniquement.

Enregistrez uniquement à la phase nommée ci-dessous. Ce sont des corps UTF-8/LF complets avec une nouvelle ligne finale ; ne collez jamais les clôtures Markdown. Les fichiers exécutables inchangés héritent de l'entrée nommée. Les versions dans des variantes distinctes ne doivent pas écraser l'original.

index.html — INSCRIPTION

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">See your work clearly.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="signup-title">
      <h2 id="signup-title">Try the demo form</h2>
      <form id="signup-form" novalidate>
        <label for="demo-email">Demo email</label>
        <input id="demo-email" name="email" type="email" autocomplete="off" aria-describedby="signup-hint">
        <p id="signup-hint">Use a fictional example.com address. Nothing is sent.</p>
        <button type="submit">Check the address locally</button>
        <p id="signup-result" role="status"></p>
      </form>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

docs/integration-note.md — DOC_MERGE

# Integration review

This note was written on main while signup work was private.

Ouvrez la palette avec Commande+Maj+P (Ctrl+Maj+P sur Ubuntu), tapez le nom exact de la commande et choisissez-le. Les actions sur une branche nommée utilisent le menu contextuel de cette branche.

1. Ouvrez gittree-merge. Choisissez ensuite New Tab et ouvrez gittree-rebase dans sa liste Recent. Chaque onglet porte le nom de son dossier, vous pouvez donc distinguer les deux.
2. Dans l'onglet gittree-merge, laissez feature/signup-form coché. Cliquez avec le bouton droit sur updated-main et choisissez Merge updated-main into feature/signup-form.
3. Sous Record it as, choisissez Always a merge commit, puis choisissez Merge une fois. Le nouveau commit a deux parents : S d'abord, puis N.
4. Passez à l'onglet gittree-rebase. Il est toujours en S et N, exactement comme vous l'avez enregistré. N'utilisez pas la copie de fusion.
5. Cliquez avec le bouton droit sur updated-main et choisissez Rebase feature/signup-form onto updated-main. Lisez Options for this rebase et laissez les deux options désactivées, puis choisissez Rebase feature/signup-form une fois.
6. Sélectionnez le commit rejoué. Son parent est N et son identifiant est nouveau. L'ancien S est toujours nommé par rescue/signup-before-rebase.
7. Dans chaque onglet, ouvrez Show Files → index.html et docs/integration-note.md. Il s'agit de la même page et de la même note dans les deux exemplaires. Revenez ensuite avec Back to Graph.
8. Comparez les deux graphiques, puis indiquez quelle règle décide du choix de cette branche avant de choisir un résultat. Conservez les deux copies telles quelles.

Pour chaque commit ordinaire du cours : Summary est le sujet indiqué, Description est vide et les options Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit et Allow Empty Commit restent désactivées. Cette leçon ne constitue pas un engagement ordinaire.

Construisez la divergence dans une copie propre et distincte du résultat de la leçon 18 (le travail que vous avez effectué dans l'application, écrit sous forme de commandes natives) :

git switch --create feature/signup-form

Enregistrez la page d'inscription complète sous index.html, puis :

git add -- index.html
git commit --quiet -m "feat: add the local signup demonstration"
git branch rescue/signup-before-rebase
BASE_SHA="$(git rev-parse HEAD~1)"
git switch --quiet --create updated-main "$BASE_SHA"

Le updated-main, enregistrez la note DOC_MERGE complète sous docs/integration-note.md, puis :

git add -- docs/integration-note.md
git commit --quiet -m "docs: add the integration review"
git switch --quiet feature/signup-form

BASE_SHA est le commit M à partir duquel les deux lignes se développent. Faites maintenant les deux copies indépendantes à partir de cet état exact (cd .. && cp -R gittree-features gittree-merge && cp -R gittree-features gittree-rebase). Dans la copie de fusion :

git merge --quiet --no-ff --no-edit updated-main
git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

Dans la copie de rebase intacte :

git rebase --quiet --no-autostash --no-update-refs --no-autosquash updated-main
git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

git rev-list --parents -n 1 HEAD imprime l'ID du commit suivi de ses parents : trois ID dans la copie de fusion, deux dans la copie de rebase. Les deux lignes HEAD^{tree} ont le même identifiant et git status --short n'imprime rien dans les deux. Les deux identifiants de commit HEAD sont différents. Vos identifiants seront différents de ceux des autres ; comparez les vôtres entre eux, pas avec cette page.

Si le sujet n'avait pas de validation propre et que updated-main était simplement en avance, git merge avancerait rapidement par défaut et ne créerait aucune validation de fusion. C'est une contribution différente et un résultat différent ; choisissez-le exprès, ne simulez jamais une fusion biparentale.

Where you end: la copie de fusion a un nouveau commit K avec les parents S et N ; la copie de rebase a S' avec le parent N, et l'ancien S est conservé par la branche de sauvetage. Les arborescences de fichiers sont égales, les deux statuts sont propres et le principal d'origine, M et le serveur sont intacts.

• En supposant qu'un graphique direct signifie que l'ancien identifiant de validation a survécu. Un rebase crée toujours de nouveaux commits.
• Démarrage du rebase à partir du résultat de la fusion. Il s'agit d'une expérience différente, et la rediffusion peut inclure la validation de fusion.
• Comparer les deux identifiants HEAD et s'attendre à ce qu'ils soient d'accord. Comparez plutôt les arbres.
• Répéter la fusion ou le rebase une fois qu'il est déjà terminé.

Ne rejetez aucun des résultats pour les forcer à correspondre. Si les arbres diffèrent, comparez les références de départ, toute résolution de conflit et tout commit supplémentaire, puis recommencez à partir de la divergence enregistrée. Une branche de sauvetage conserve uniquement l'historique engagé ; il ne conserve pas les fichiers non validés.

Répondez à chaque question, puis lisez pourquoi. Les questions marquées « Obligatoire » comptent pour terminer la leçon.

1. Question 1 de 6

   Question 1 de 6

   À partir du même début, vous fusionnez updated-main dans feature/signup-form dans une copie et rebasez feature/signup-form sur updated-main dans une autre. Combien de parents le nouveau conseil du sujet comporte-t-il dans chaque copie ?

   Choisissez une réponse.

   Les deux exemplaires : deux.

   Les deux exemplaires : un.

   Fusionner la copie : deux. Copie de rebase : une.

   Copie de fusion : une. Copie de rebase : deux.

   Vérifier la réponse
2. Question 2 de 6

   Question 2 de 6

   Lesquels de ces éléments sont identiques dans les deux copies une fois la fusion et le rebase terminés sans conflits ?

   Choisissez chaque réponse qui s'applique.

   Le commit avec lequel votre branche de sujet a commencé

   L'arborescence des fichiers du commit tip

   L’ID du commit de pointe

   Le contenu de docs/integration-note.md

   Vérifier la réponse
3. Question 3 de 6

   Question 3 de 6Obligatoire

   Après le rebase, qu'est-il arrivé à votre commit de sujet d'origine S ?

   Choisissez une réponse.

   Un nouveau commit S′ avec un nouvel ID a été créé ; l'ancien S n'est accessible que via la branche de secours.

   S a conservé son identifiant et seul son parent a changé.

   S a été immédiatement supprimé du référentiel.

   S a été poussé vers le serveur.

   Vérifier la réponse
4. Question 4 de 6

   Question 4 de 6

   Modifiez l'entrée : votre sujet n'a pas de commit propre et updated-main est simplement en avance sur lui. Vous fusionnez avec le mode par défaut, "Avance rapide si possible, sinon une validation de fusion". Ce qui se produit?

   Choisissez une réponse.

   Git refuse, car les branches n'ont pas divergé.

   Un commit de fusion avec deux parents est toujours créé.

   L'étiquette de branche avance et aucune validation de fusion n'est créée.

   Chaque commit est réécrit avec un nouvel identifiant.

   Vérifier la réponse
5. Question 5 de 6

   Question 5 de 6Obligatoire

   Un collègue a déjà tiré feature/signup-form et s'appuie sur cela. Vous souhaitez que l'historique de main reste bien rangé. Quel est le choix sûr ?

   Choisissez une réponse.

   Rebasez-le et forcez-le, car un graphique droit est plus propre.

   Supprimez la branche et créez-la à nouveau avec le même nom.

   Fusionnez updated-main dans la branche afin que leurs commits conservent leurs identifiants.

   Réinitialisez la branche sur updated-main.

   Vérifier la réponse
6. Question 6 de 6

   Question 6 de 6Obligatoire

   Quelles relectures montrent que la comparaison était juste et montrent comment elle s'est terminée ?

   Choisissez chaque réponse qui s'applique.

   Les deux exemplaires portaient le même S et N avant de commencer.

   git rev-parse HEAD^{tree} imprime le même ID dans les deux copies.

   git rev-list --parents -n 1 HEAD imprime trois identifiants pour la copie de fusion et deux pour la copie de rebase.

   git rev-parse HEAD imprime le même identifiant dans les deux copies.

   Vérifier la réponse

Signalez les deux listes parent, les deux ID HEAD et les deux ID d'arborescence. Expliquez pourquoi des ID d'arbre égaux à côté de différents ID HEAD sont le résultat attendu. Prédisez ensuite, sans le faire, ce que fait une fusion par défaut lorsque le sujet n'a pas de validation propre.

• Même début, histoire différente.
• Des arbres égaux ne signifient pas une histoire égale.
• Fusionnez lorsque d’autres ont vos commits. Rebasez uniquement les fichiers privés.

• Fusionner les branches avec un historique divergé (leçon 18)
• Comprendre les fusions rapides (leçon 19)
• Rebaser un travail non publié sur une nouvelle base (leçon 20)
• Rebase interactif dans une interface graphique
• Télécharger GitTree

Rebase — إعادة تأسيس; rejouer — إعادة تطبيق; branche de sauvetage — فرع حفظ.