Fusionner des branches avec un historique divergent

• Reconnaissez la divergence avec l’ascendance.
• Choisissez un mode d'enregistrement de fusion explicite.
• Vérifiez les deux parents et le contenu combiné.
• Séparez la fusion locale de la publication sur le serveur.

Commencez là où la leçon 17 s'est terminée : main avec le commit README de Maya, clean ; les fiches de fonctionnalités/tarifications publiées sont toujours F1, dérivées de H5. Vous enregistrez et validez MAIN_ACCESSIBLE en guise de préparation, de sorte que main et la fonctionnalité aient chacun des validations indépendantes.

La vidéo a été enregistrée avec Git 2.52.0 et GitTree 2.0 sur Ubuntu 24.04 : la page, son commit et la fusion ont été réalisés dans l'application ; l'état avant, l'avance rapide refusée dans une copie séparée et les vérifications (y compris les propres lint, test et build du projet) ont été exécutées 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.

La divergence signifie qu'aucune des pointes n'est simplement le descendant vers lequel l'autre branche peut avancer rapidement. Git trouve un ancêtre commun et combine les modifications relatives à celui-ci. Un nom de branche à lui seul ne peut pas vous dire si une validation de fusion est nécessaire.

Une validation de fusion enregistre deux parents dans l'ordre. Le premier parent est le conseil précédent de la branche extraite ; le deuxième est le côté fusionné. Les commits de fonctionnalités existants conservent leur identité ; un nouveau commit de fusion relie leur ascendance.

Aucun conflit textuel n'est une preuve d'exactitude sémantique. Vérifiez la section principale focalisable, le flux de travail et le rappel de Leo dans le fichier complet ; exécuter les contrôles existants. Une fusion locale ne met pas à jour l'origine jusqu'à un push autorisé distinct.

Préparation et fusion, déplacement local main/HEAD et mise à jour index/work. La référence de fonctionnalité reste F1. Les branches d'origine et la v0.1.0 conservent leurs conseils antérieurs.

Lors de la sauvegarde principale MAIN_ACCESSIBLE, placez uniquement index.html et validez le correctif : rendez le point de repère principal focalisable. Cela rend l'entrée de fusion native/application explicite ; ne validez pas le fichier MERGED déjà combiné avant la fusion.

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 — MAIN_ACCESSIBLE

<!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>
  </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>

index.html — FUSIONNÉ

<!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>
  </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>

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. Enregistrez MAIN_ACCESSIBLE via Afficher les fichiers → index.html → Enregistrer ; examiner uniquement l'ajout de tabindex.
2. Afficher les modifications de travail ; Fichier de scène index.html ; commit fix : rendre le point de repère principal focalisable avec les options ordinaires désactivées.
3. Inspecter l'ascendance des graphiques des cartes principales et des fonctionnalités/tarifications ; garder le principal vérifié.
4. Sous Local, ouvrez le dossier feature, cliquez avec le bouton droit sur pricing-cards → Merge feature/pricing-cards into main. La boîte de dialogue suit avec Record it as.
5. Dans Record it as, les choix sont Avance rapide si possible, sinon une validation de fusion ; Always a merge commit ; Avance rapide uniquement ; et Squash en changements par étapes (pas de validation). Sélectionnez Toujours une validation de fusion. Annulez si l'aperçu réel montre des chemins inattendus ou des conflits.
6. Choisissez Fusionner une fois et attendez la fin réelle. Ne remplacez pas Squash par des changements par étapes.
7. Inspectez les deux parents du commit résultant et comparez le fichier index.html complet à MERGED ; vérifiez les trois changements indépendants.
8. Exécutez les vérifications locales et les requêtes de statut propre ; quittez main lors de la fusion locale, sans Push After Commit. Le sujet de fusion de l'application est « Fusionner les cartes de fonctionnalités/tarifications de la branche » ; il n'est pas nécessaire qu'il corresponde au message natif ci-dessous.

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.

Après avoir sauvegardé MAIN_ACCESSIBLE, préparation native et fusion :

git add -- index.html
git commit --quiet -m "fix: make the main landmark focusable"
git branch course-before-merge
git merge --quiet --no-ff feature/pricing-cards --message "merge: combine workflow cards with accessibility"
git log -1 --format=%s
git rev-list --parents -n 1 HEAD
git status --short

Sujet réel :

merge: combine workflow cards with accessibility

La requête parent émet un SHA de fusion réel suivi d'exactement deux SHA parents ; Les identifiants varient. Le fichier index.html fusionné complet correspondait à MERGED octet par octet dans le luminaire ; le statut était vide. Le sujet natif explicite ne doit pas nécessairement correspondre au sujet généré par l'application : acceptez le message réel de l'application si l'ascendance/le contenu est d'accord, ne superposez jamais un faux message natif.

npm run --silent lint
npm test -- --test-reporter=tap
npm run --silent build

Exécutez-les sur le point de contrôle fusionné ; le texte source et le nombre de parents à eux seuls ne prouvent pas les vérifications. La suite de luminaires comporte six tests. Une tentative distincte de ff uniquement sur l'entrée divergée doit refuser plutôt que de choisir silencieusement ce mode de fusion.

Where you end: Points principaux pour fusionner M avec le premier parent le conseil principal préparé et le deuxième parent F1 ; La page complète MERGÉE contient des cartes de flux de travail, un pied de page Leo et un principal focalisable. Index/travail propre ; pas de poussée à distance.

• Fusionner dans la mauvaise direction.
• Appeler une courge une fusion biparentale.
• Faire confiance à l’aperçu sans conflit comme preuve sémantique.

Si une véritable fusion s'arrête, conservez son état de fonctionnement et utilisez le workflow de conflit/abandon enseigné plus tard ; n'émettez pas de réinitialisation sans rapport. Avant une fusion native terminée, course-before-merge conserve uniquement l'ancienne astuce validée, et non les octets de travail arbitraires.

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 différencie un commit de fusion ?

   Choisissez une réponse.

   Sa couleur

   Son sujet contient une fusion

   Plusieurs parents

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

   Question 2 de 6

   Quelles preuves sont nécessaires ?

   Choisissez chaque réponse qui s'applique.

   Les deux rôles de parents

   Uniquement un label sans conflits

   Pleine page combinée

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

   Question 3 de 6Obligatoire

   Qu'arrive-t-il à l'identité de la F1 ?

   Choisissez une réponse.

   Il reste inchangé

   Il est rejoué en F1′

   Cela devient la racine sans parent de main

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

   Question 4 de 6Obligatoire

   Choisissez ff-only sur cette entrée divergée : résultat ?

   Choisissez une réponse.

   Suppression de fonctionnalités

   Validation de fusion automatique

   Refus

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

   Question 5 de 6

   Aucun conflit textuel signifie que les tests sont inutiles ?

   Choisissez une réponse.

   Oui

   Seul le nombre de parents compte

   Non

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

   Question 6 de 6Obligatoire

   Quelle est la portée finale ?

   Choisissez chaque réponse qui s'applique.

   M principale locale avec deux parents

   Tout s'est poussé automatiquement

   Fonctionnalité F1 et références du serveur inchangées

   Vérifier la réponse

Vérifiez les octets fusionnés exacts et deux parents réels, avec F1 inchangé. Prévoyez que l'avance rapide uniquement sur l'entrée divergente d'origine refuse ; tester uniquement dans une copie séparée.

• La divergence est une relation d'ascendance.
• La fusion préserve les anciennes identités de commit.
• Les vérifications du contenu et des parents sont toutes deux requises.

• Créez une branche de fonctionnalités et retirez uniquement la référence jetable (leçon 9)
• Pousser les commits et publier une branche (leçon 13)
• Télécharger GitTree

Fusionner — دمج; commit de fusion — إيداع دمج; ancêtre commun — سلف مشترك; premier parent — الأب الأول.