Rebaser un travail inédit sur une nouvelle base

• Identifiez la plage de relecture privée exacte.
• Protégez l’ancien historique engagé avant de le rejouer.
• Reconnaître les identités de commit recréées.
• Vérifiez le parent et l'arborescence résultante complète.

Commencez à partir d'une copie séparée du résultat de la leçon 18 (le principal est la fusion M, propre) : la fonctionnalité/le formulaire d'inscription du sujet privé contient un commit S, la mise à jour principale contient un commit N différent, tous deux sur M, et le sauvetage/l'inscription avant le rebase pointe également vers S. Le sujet est extrait, propre et non publié.

La vidéo a été enregistrée avec Git 2.52.0 et GitTree 2.0 sur Ubuntu 24.04 : le sujet privé et la base la plus récente ont été construits dans le terminal ; le rebase, son dialogue et les vérifications du résultat ont été effectués dans l'application ; le résultat a été relu dans le terminal. La rediffusion native ci-dessous a été exécutée sur une copie jetable et a donné le même résultat. Rien n'a été exécuté sur macOS ou Windows, et Ubuntu est le seul système Linux enregistré. Le niveau Git source de GitTree est 2.39.0.

GitTree vous demande de vous connecter ; le plan gratuit couvre ensuite chaque étape ici. Aucun compte fournisseur, Pro/essai, identifiant API ou service Internet n'est nécessaire. Une origine locale nue n'est pas GitLab ou CI. Toutes les identités utilisent example.com ; n'exécutez jamais cette leçon dans une extraction de source.

Effectuez des mutations via GitTree ou le chemin natif à des entrées identiques, pas les deux consécutivement. Une vérification en lecture seule peut suivre l'une ou l'autre. Toute préparation décrite comme un travail de terminal est étiquetée préparation native, jamais une fonctionnalité d'application inventée.

Rebase sélectionne les commits uniques au sujet actuel et rejoue leurs modifications sur une nouvelle base. Cela ne bouge pas les anciens engagements eux-mêmes ; cela crée de nouveaux commits avec de nouveaux parents et généralement de nouveaux identifiants.

La branche source doit être la branche actuelle prévue. Dans cet appareil, S ajoute une inscription et N ajoute un document différent, donc la relecture est sans conflit, mais cela ne garantit pas la sécurité des rebases arbitraires.

L’histoire publiée est une frontière de coordination. Ces commits sont intentionnellement privés ; ne rebasez pas la fonctionnalité de tarification déjà publiée simplement pour rendre son graphique droit. Une référence de secours protège l'ascendance validée, pas le texte non enregistré.

Caractéristique et HEAD avance S → S ' ; index/travail devient l’arbre combiné. N/updated-main, Rescue S et original main/M restent fixes. Pas de mutation de serveur ni de push automatique.

Commencez à partir d'une copie ordinaire séparée du projet telle que la leçon 18 l'a laissé (la principale est la fusion M). Les fonctionnalités originales de Gittree restent préservées ; n'exécutez pas ce scénario dans l'original ou dans une extraction de source. Effectuez ensuite la préparation exacte ci-dessous. La signature de la démo Repo-local est désactivée et GitTree Demo <demo@example.com> est l'identité.

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.

Palette : Commande+Maj+P (Ctrl+Maj+P sur Ubuntu) ; tapez la commande exactement nommée et sélectionnez-la. Les actions de référence nommée utilisent le menu contextuel de cette ligne, et non un raccourci de palette sans argument.

1. Préparez la branche exacte de divergence et de sauvetage en utilisant la configuration native étiquetée ci-dessous ; aucune branche publiée n'est réécrite.
2. Dans l'application, confirmez la fonctionnalité/le formulaire d'inscription extrait, propre et non publié ; inspectez S et N.
3. Faites un clic droit sur updated-main dans le graphique → Rebase feature/signup-form onto updated-main ; la boîte de dialogue nomme la branche actuelle et la cible.
4. Lisez Options for this rebase. Laissez Stash local changes and put them back et Move the branches that point into these commits désactivés. La boîte de dialogue indique que l'ancienne fonctionnalité/formulaire d'inscription est conservée sous refs/ogt/trash.
5. Choisissez Rebase feature/signup-form une fois ; attendez l'avis indiquant que le rebase est terminé. S'il s'arrête, conservez son état de fonctionnement plutôt que de cliquer à nouveau.
6. Inspectez le parent S′ N et le sujet. Comparez les anciens/nouveaux identifiants réels, et non les étiquettes de modèle en tant que sortie du terminal.
7. Inspectez l'intégralité de SIGNUP et DOC_MERGE dans l'arborescence résultante ; La branche de sauvetage pointe toujours vers l'ancien S.
8. Vérifiez l'état propre et aucune opération de rebase ; laissez le main/M d'origine et toutes les références du serveur seuls.

Pour chaque commit ordinaire : le résumé est le sujet indiqué ; Description vide ; Modifier la validation précédente, ignorer les crochets, ajouter une signature par un auteur différent, appuyer après la validation et autoriser la validation vide ; pas de co-auteurs. Mettez en scène uniquement les fichiers nommés, puis validez les modifications dans N fichiers une fois (fichier pour un) ou Commande+Entrée comme alternative. Attendez le vrai résultat. Une leçon qui modifie explicitement ne change que cette option indiquée.

Dans une copie séparée de la leçon 18/M, créez le sujet privé :

git switch --create feature/signup-form

Placez le fichier SIGNUP enregistré sur index.html (la vidéo a enregistré les fichiers de la leçon dans ~/Downloads et utilise cp ~/Downloads/SIGNUP.html 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"

Sur le fichier principal mis à jour, placez DOC_MERGE dans docs/integration-note.md (cp ~/Downloads/DOC_MERGE.md 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 parent M mesuré avant la validation de l'inscription privée. Le sujet et le main mis à jour ont désormais un commit indépendant ; Rescue/signup-before-rebase conserve l'ancien sujet. Rien de ce sujet n'est publié.

Alternative de relecture native :

git rebase --quiet --no-autostash --no-update-refs --no-autosquash updated-main
git log -1 --format=%s
git rev-parse HEAD HEAD^ updated-main rescue/signup-before-rebase
git status --short

Sujet observé :

feat: add the local signup demonstration

La HEAD réelle diffère du S sauvé ; HEAD^ est égal à update-main/N. Le document indépendant et le corps exact de l'INSCRIPTION demeurent tous deux ; le statut court est silencieux. Arrêtez-vous sur une entrée publiée/sale inattendue au lieu d'ajouter des options de force. Pour la variante conflit, voir leçon 23 ; ne traitez pas un rebase arrêté comme déjà terminé.

Where you end: points de fonctionnalité/formulaire d'inscription S', parent N, avec inscription plus DOC_MERGE ; l'ancien S survit dans le sauvetage/inscription avant le rebase. Aucune opération active, propre ; main/M et serveur inchangés.

• En supposant qu'un graphique direct signifie que l'ancien identifiant de validation a survécu.
• Traiter le volet alternatif comme le point de contrôle d'origine.
• Répéter une mutation terminée après le succès de l'application.

Avant de rejouer, la branche de sauvetage conserve S. Si l'opération s'arrête, inspectez la bannière et résolvez ou abandonnez explicitement ; un rebase terminé n'est pas annulé par rebase --abort. Ne supposez jamais que Native Replay a écrit un journal GitTree.

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

   Qu'est-ce qui est rejoué ?

   Choisissez une réponse.

   Chaque fichier du référentiel à l'aveugle

   Le serveur distant

   Changements de sujet privé

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

   Question 2 de 6

   Que faut-il vérifier ?

   Choisissez chaque réponse qui s'applique.

   Branche actuelle et cible

   Range privé et secours réf

   Uniquement la couleur du graphique

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

   Question 3 de 6Obligatoire

   S rejoué sur N : parent ?

   Choisissez une réponse.

   Le commit principal mis à jour N

   S en tant que son propre parent

   Ancien M uniquement

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

   Question 4 de 6Obligatoire

   Modification de l'entrée : la même ligne de héros a été modifiée des deux côtés.

   Choisissez une réponse.

   Toujours pas de conflits

   Jeter automatiquement un côté

   Un conflit peut arrêter la relecture

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

   Question 5 de 6

   Est-ce que --abort peut annuler un rebase déjà terminé ?

   Choisissez une réponse.

   Il annule les push du serveur

   Toujours

   Aucune opération active n'existe

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

   Question 6 de 6Obligatoire

   Qu'est-ce qui prouve ce résultat ?

   Choisissez chaque réponse qui s'applique.

   Nouvel identifiant et parent N

   Old S sauvé, fichiers complets nettoyés

   Message inchangé uniquement

   Vérifier la réponse

Prouvez que le nouveau HEAD diffère du sauvetage, que son parent est égal à N et que les octets complets d'inscription/document sont d'accord. Prédisez les conflits si les deux camps changent la même ligne de héros, dans une copie séparée de la leçon 23.

• Rebase recrée les commits.
• Choisissez la branche actuelle et la cible explicitement.
• L’historique privé et la portée de la récupération sont importants.

• Fusionner les branches avec un historique divergé (leçon 18)
• Comprendre les fusions rapides (leçon 19)
• Créez une branche de fonctionnalités et retirez uniquement la référence jetable (leçon 9)
• Télécharger GitTree

Rebase — إعادة تأسيس; rejouer — إعادة تطبيق; réf. de secours — مرجع حفظ.