Tirez avec avance rapide, fusionnez ou rebasez

• Séparez la récupération de l’intégration pull.
• Comparez trois choix politiques explicites.
• Reconnaître le refus de ff-only comme un résultat politique.
• Examinez les paramètres de stratégie d’application en amont et persistants.

Commencez par le projet de cours tel que la leçon 11 l'a laissé, avec le principal amené au commit récupéré par Leo ; appelez ce commit M. Vous disposez alors de trois copies ordinaires d'une divergence : un sujet privé avec un commit S et une branche de serveur mise à jour principale avec un commit N différent, tous deux sur M. Le sujet privé est actuel et propre. Chacun pointe origin uniquement vers un nouveau serveur nu contenant update-main/N et suit origin/updated-main ; l'ancien prix publié/télécommande principale n'est pas muté.

La vidéo a été enregistrée avec Git 2.52.0 et GitTree 2.0 sur Ubuntu 24.04 : la divergence, la branche de secours et le nouveau serveur ont été construits dans le terminal ; les trois extractions, les vues des résultats, le fichier de stratégie et la restauration en mode Pull ont été effectués dans l'application ; les résultats ont été vérifiés dans le terminal. 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.

Pull est une récupération suivie de la politique d'intégration sélectionnée ; ce n'est pas synonyme de rafraîchissement. Une phase de récupération peut mettre à jour les références de suivi même si ff-only refuse ultérieurement de déplacer la branche locale.

Sur un S/N privé divergé, ff-only refuse, la fusion préserve les deux chemins et le rebase rejoue la validation privée sur la base récupérée. Ne changez pas de mode en silence pour faire disparaître un refus.

Les commandes du mode Pull de la palette mettent à jour general.pullMode, une préférence à l’échelle de l’application, et non un indicateur Git unique. Enregistrez/restaurez le paramètre précédent dans l'application d'enregistrement. Les indicateurs d'extraction explicites natifs ci-dessous ne modifient pas ce paramètre d'application.

Chaque extraction récupère son origine sandbox. FF uniquement laisse le sujet/index/travail à S ; fusionner et rebaser mettre à jour uniquement leur propre sujet et leurs propres fichiers. Aucune branche de serveur n'est poussée. Le choix de la stratégie de palette modifie également les préférences à l’échelle de l’application jusqu’à ce qu’elles soient restaurées.

Commencez à partir d’une copie ordinaire séparée du projet de cours propre tel que la leçon 11 l’a laissé. 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. (Un plan de cours antérieur a démarré cette leçon à partir du résultat d'une leçon de fusion ultérieure ; cette leçon n'est pas encore enregistrée, la vidéo utilise donc le projet de la leçon 11 et les mêmes étapes.) 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é à moins qu'un coéquipier ne soit explicitement nommé.

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.

docs/pull-policy.md — DOC_PULL

# Pull policy

Fetch first and inspect ancestry.
Use fast-forward only when no integration decision is needed.
Merge preserves existing commit identities; rebase recreates private commits.
Never rewrite someone else's published work without coordination.

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 les trois copies isolées réelles et leur propre serveur/amont ci-dessous ; enregistrez le general.pullMode précédent avant de choisir une stratégie.
2. Dans la copie FF, palette Pull : Avance rapide uniquement, puis le bouton Pull de la barre d'outils ; attendre le véritable refus de divergence. L'avis de l'application indique « la fonctionnalité/le formulaire d'inscription ne peut pas avancer rapidement », indique que les deux parties se sont engagées à ce que l'autre ne le fasse pas, que rien n'a été modifié et propose à Resolve… de fusionner, de rebaser ou de réinitialiser. Il reste jusqu'à ce que vous le supprimiez, alors supprimez-le avant la copie suivante.
3. Inspectez l'astuce du sujet/le travail inchangé même si l'origine/la mise à jour principale récupérée est actuelle ; n'appuyez pas sur Force Push….
4. Dans la copie de fusion intacte, choisissez Tirer : Avance rapide si possible, Sinon Fusionner, puis le bouton Tirer de la barre d'outils ; inspectez le résultat réel des deux parents.
5. Dans la copie Rebase intacte, choisissez Pull : Rebase, puis Pull ; Le sujet actuel est privé, aucun cache automatique n'est nécessaire.
6. Vérifiez S 'recréé sur N, fusionnez les parents et égalisez les arbres complets. Conservez chaque résultat indépendamment.
7. Enregistrez le DOC_PULL complet sous docs/pull-policy.md dans une copie pratique uniquement après avoir conservé les instantanés comparés ; laissez-le sans engagement ici.
8. Restaurez explicitement le mode Pull précédent de l'application d'enregistrement ; vérifiez qu'aucune poussée automatique ou aucun changement principal d'origine ne s'est produit.

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 propre distincte du projet, apportez d'abord main au commit récupéré par Leo (c'est-à-dire M), puis créez le sujet privé :

git merge --ff-only --quiet origin/main
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é.

À partir de cette copie de pré-rebase, préparez un serveur new contenant uniquement N :

git clone --quiet --bare --single-branch --branch updated-main --no-local . ../gittree-pull-origin.git

Faites trois copies ordinaires de la même entrée avec cp -R <source-demo-copy> <new-copy> alors qu'aucune opération Git/app n'est active, ou des copies vérifiées équivalentes du système de fichiers préservant .git. Dans chaque copie, remplacez origin par l'URL du fichier mesuré pour ce nouveau serveur, récupérez et définissez le sujet en amont ; ne reciblez jamais l’original :

git remote set-url origin "<measured-file-url>"
git fetch --quiet --prune origin
git branch --set-upstream-to=origin/updated-main feature/signup-form

Utilisez l'URL du fichier mesuré à la place de l'espace réservé. En copie FF :

git pull --quiet --ff-only origin updated-main

Sortie mesurée 128 ; extrait diagnostique :

hint: Diverging branches can't be fast-forwarded, you need to either:
hint:
hint: 	git merge --no-ff
hint:
hint: or:
hint:
hint: 	git rebase
hint:
hint: Disable this message with "git config set advice.diverging false"
fatal: Not possible to fast-forward, aborting.

Dans une copie de fusion séparée :

git pull --quiet --no-rebase --no-edit origin updated-main

Dans une copie Rebase séparée :

git pull --quiet --rebase origin updated-main

Tous deux réussirent ; les ID d'arbre final réels correspondent, la fusion a deux parents et en rejoue un. Pour chaque inspection :

git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

Les SHA varient ; les statuts étaient propres avant la pratique facultative du fichier de stratégie. Aucune commande ne pousse une branche.

Where you end: La copie FF uniquement reste en S avec refus après récupération. La copie de fusion ajoute une intégration biparentale ; La copie de rebase crée S' sur N. Les arbres de fusion/rebase sont d'accord ; pas de poussée. Conserver le fichier de stratégie en tant que pratique non validée après comparaisons uniquement.

• 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.

Le refus de FF n'est pas une perte de données. Inspectez les références récupérées/locales et choisissez une politique révisée pour cette copie. Si la fusion/rebase s'arrête, résolvez/Continuer ou explicitement Abandonner ; n'exécutez pas un autre pull sur une opération active.

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 que tirer ici ?

   Choisissez une réponse.

   Récupérer l'intégration puis sélectionnée

   Pousser et actualiser

   Sélectionnez uniquement une ligne de graphique

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

   Question 2 de 6

   Que peut-il se passer en cas de refus de ff uniquement ?

   Choisissez chaque réponse qui s'applique.

   Écrasement automatique

   Astuce locale inchangée

   Référence de suivi actualisée

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

   Question 3 de 6Obligatoire

   Replay privé sur N : parent résultant ?

   Choisissez une réponse.

   Deux parents fusionnent toujours

   Aucun parent

   Le commit N, la nouvelle base

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

   Question 4 de 6Obligatoire

   Changer le travail en cours en sujet partagé publié : rebase toujours des conseils automatiques ?

   Choisissez une réponse.

   Non, coordonnons d’abord la politique

   Supprimer d'abord la télécommande

   Toujours oui

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

   Question 5 de 6

   La commande de stratégie de palette ne change qu'un seul pull ?

   Choisissez une réponse.

   Non, la préférence à l'échelle de l'application persiste

   Oui

   Ça change le serveur

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

   Question 6 de 6Obligatoire

   Qu'est-ce qui prouve la comparaison ?

   Choisissez chaque réponse qui s'applique.

   Aucun résultat signifie que toutes les politiques sont égales

   Arbres finaux réussis égaux et préférence restaurée

   Refus contre les deux listes de parents réussies

   Vérifier la réponse

Expliquez quel état a changé dans la copie refusée, comparez les deux arborescences et parents réussis, puis écrivez la politique DOC_PULL complète. Vérifiez que les préférences de l'application d'enregistrement ont été restaurées.

• Pull inclut une politique d’intégration.
• Le refus peut suivre une récupération réussie.
• La persistance des politiques nécessite un examen explicite.

• Récupérer la modification d'un coéquipier sans remplacer votre page (leçon 11)
• Connecter une télécommande sans la confondre avec une amont (leçon 10)
• Télécharger GitTree

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