Fusionar versus rebase: elegir con un gráfico

• Comience a fusionar y rebase a partir de copias idénticas, para que la comparación sea justa.
• Lea los dos padres de una confirmación de fusión y el nuevo padre único de una confirmación rebasada.
• Explique por qué dos copias pueden terminar con los mismos archivos y aun así tener historias diferentes.
• Elija con una regla: reescriba solo las confirmaciones que nadie más tenga.

Necesita dos copias separadas de la divergencia de la lección 20, denominadas gittree-merge y gittree-rebase. En cada copia, la rama feature/signup-form contiene una confirmación suya (llámela S), la rama updated-main contiene una confirmación diferente (llámela N), ambas comenzaron desde la misma confirmación M, y rescue/signup-before-rebase apunta a S. La rama del tema está desprotegida y el árbol de trabajo está limpio. No hagas la segunda copia del resultado de la primera.

Todo aquí es local y en el plan gratuito (GitTree te pide que inicies sesión): sin cuenta de alojamiento, sin proveedor, sin Internet. Cada identidad es ficticia (ejemplo.com) y nunca debes ejecutar esta lección dentro de un proyecto real.

Realice los cambios en GitTree o con los comandos nativos de Git, no ambos en la misma copia. Leer el resultado después siempre es seguro. Las etiquetas del menú provienen de las propias cadenas de GitTree 2.0; Los comandos nativos se ejecutaron con Git 2.43 en copias desechables. Los pasos GitTree no se ejecutaron en macOS, Windows o Linux; Los atajos de la aplicación usan Comando en macOS donde esta página escribe Ctrl.

Una comparación sólo es justa cuando ambas copias parten de las mismas referencias y los mismos archivos. Si fusiona primero y luego modifica la base de ese resultado, está haciendo una pregunta diferente: la repetición ahora tiene una confirmación de fusión en su rango.

Merge mantiene ambas líneas de trabajo. Agrega una nueva confirmación, K, con dos padres: primero S, luego N. S y N mantienen sus ID.

Rebase reproduce tu confirmación encima de N. El resultado, S′, tiene el mismo cambio que S pero un nuevo padre, y el ID de una confirmación incluye su padre, por lo que S′ tiene un nuevo ID. La antigua S sobrevive sólo porque la rama de rescate todavía apunta hacia ella.

Cuando nada entra en conflicto, ambas copias terminan con el mismo árbol de archivos. Árboles iguales no significan historia igual: un gráfico mantiene un diamante, el otro una línea recta y los ID de confirmación difieren.

Cuál es la correcta no es una cuestión de gustos. Si otras personas ya tienen sus confirmaciones, reproducirlas rompe sus copias, así que fusione. Si las confirmaciones son privadas, una rebase es segura y proporciona un historial lineal si su equipo lo prefiere. Ninguno de los dos mejora el código.

En cada copia sólo se mueve la rama temática. El servidor, updated-main y el principal original no se tocan.

Haz una divergencia y luego cópiala dos veces. Comience desde una copia ordinaria separada del proyecto como lo dejó la lección 18 (la principal es la confirmación de fusión M). Deje su gittree-features original intacto y nunca lo ejecute en una compra de código fuente. La identidad de la demostración es GitTree Demo, demo@example.com, con la firma desactivada solo en este repositorio.

Guarde solo en la fase que se menciona a continuación. Estos son cuerpos UTF-8/LF completos con una nueva línea final; Nunca pegues vallas Markdown. Los archivos ejecutables sin cambios heredan la entrada nombrada. Las versiones en variantes separadas no deben sobrescribir el original.

index.html — REGÍSTRESE

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

Abra la paleta con Comando+Mayús+P (Ctrl+Mayús+P en Ubuntu), escriba el nombre exacto del comando y selecciónelo. Las acciones en una rama con nombre utilizan el menú contextual de esa rama.

1. Abra gittree-merge. Luego elija New Tab y abra gittree-rebase de su lista Recent. Cada pestaña tiene el título de su carpeta, para que pueda distinguirlas.
2. En la pestaña gittree-merge, mantenga feature/signup-form marcado. Haga clic derecho en updated-main y elija Merge updated-main into feature/signup-form.
3. En Record it as elige Always a merge commit y luego elige Merge una vez. La nueva confirmación tiene dos padres: primero S, luego N.
4. Cambie a la pestaña gittree-rebase. Todavía está en S y N, exactamente como lo guardaste. No utilice la copia combinada.
5. Haga clic derecho en updated-main y elija Rebase feature/signup-form onto updated-main. Lea Options for this rebase y deje ambas opciones desactivadas, luego elija Rebase feature/signup-form una vez.
6. Seleccione la confirmación reproducida. Su padre es N y su ID es nuevo. La antigua S todavía lleva el nombre de rescue/signup-before-rebase.
7. En cada pestaña abra Show Files → index.html y docs/integration-note.md. Son la misma página y la misma nota en ambos ejemplares. Luego regresa con Back to Graph.
8. Compara las dos gráficas, luego di qué regla decide la elección de esta rama antes de elegir un resultado. Mantenga ambas copias como están.

Para cada confirmación ordinaria del curso: Summary es el asunto indicado, Description está vacío y las opciones Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit y Allow Empty Commit permanecen desactivadas. Esta lección no implica un compromiso común y corriente.

Cree la divergencia en una copia limpia separada del resultado de la lección 18 (el trabajo que realizó en la aplicación, escrito como comandos nativos):

git switch --create feature/signup-form

Guarde la página de REGISTRO completa como index.html y luego:

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"

El updated-main guarda la nota DOC_MERGE completa como docs/integration-note.md y luego:

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

BASE_SHA es la confirmación M a partir de la cual crecen ambas líneas. Ahora haga las dos copias independientes desde este estado exacto (cd .. && cp -R gittree-features gittree-merge && cp -R gittree-features gittree-rebase). En la copia combinada:

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

En la copia rebase intacta:

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 el ID de la confirmación seguido de sus padres: tres ID en la copia combinada, dos en la copia rebase. Las dos líneas HEAD^{tree} tienen el mismo ID y git status --short no imprime nada en ambas. Los dos ID de confirmación HEAD son diferentes. Tus identificaciones serán diferentes a las de cualquier otra persona; compara los tuyos entre sí, no con esta página.

Si el tema no tuviera ninguna confirmación propia y updated-main simplemente estuviera por delante, git merge avanzaría rápidamente de forma predeterminada y no crearía ninguna confirmación de fusión. Ésa es una entrada diferente y un resultado diferente; elíjalo a propósito, nunca finja una fusión de dos padres.

Where you end: la copia fusionada tiene una nueva confirmación K con los padres S y N; la copia rebase tiene S′ con padre N, y la rama de rescate conserva la antigua S. Los árboles de archivos son iguales, ambos estados están limpios y el principal original, M y el servidor están intactos.

• Suponer un gráfico directo significa que el antiguo ID de confirmación sobrevivió. Una rebase siempre crea nuevas confirmaciones.
• Iniciando la rebase a partir del resultado de la fusión. Ese es un experimento diferente y la repetición puede incluir la confirmación de fusión.
• Comparando los dos HEAD ID y esperando que coincidan. Compara los árboles en su lugar.
• Repetir la fusión o la rebase una vez que ya haya finalizado.

No descartes ninguno de los resultados para obligarlos a coincidir. Si los árboles difieren, compare las referencias iniciales, cualquier resolución de conflicto y cualquier compromiso adicional, luego comience nuevamente desde la divergencia guardada. Una rama de rescate mantiene únicamente la historia comprometida; no guarda archivos no confirmados.

Responda cada pregunta y luego lea por qué. Las preguntas marcadas como "Obligatorias" cuentan para completar la lección.

1. Pregunta 1 de 6

   Pregunta 1 de 6

   Desde el mismo comienzo, fusionas updated-main en feature/signup-form en una copia y rebasas feature/signup-form en updated-main en otra. ¿Cuántos padres tiene el nuevo compromiso de sugerencias del tema en cada copia?

   Elija una respuesta.

   Ambos ejemplares: dos.

   Ambos ejemplares: uno.

   Fusionar copia: dos. Copia rebase: una.

   Copia fusionada: una. Copia rebase: dos.

   comprobar respuesta
2. Pregunta 2 de 6

   Pregunta 2 de 6

   ¿Cuáles de estos son iguales en ambas copias una vez que la fusión y el cambio de base hayan finalizado sin conflictos?

   Elija cada respuesta que corresponda.

   La rama de confirmación de su tema comenzó con

   El árbol de archivos del compromiso de sugerencia.

   El ID de la confirmación de propina.

   El contenido de docs/integration-note.md

   comprobar respuesta
3. Pregunta 3 de 6

   Pregunta 3 de 6Requerido

   Después de la rebase, ¿qué pasó con el compromiso S del tema original?

   Elija una respuesta.

   Se creó una nueva confirmación S′ con una nueva ID; Solo se puede acceder a la antigua S a través de la rama de rescate.

   S mantuvo su ID y solo cambió su padre.

   S fue eliminado del repositorio de inmediato.

   S fue enviado al servidor.

   comprobar respuesta
4. Pregunta 4 de 6

   Pregunta 4 de 6

   Cambie la entrada: su tema no tiene confirmación propia y updated-main simplemente está por delante de él. Se fusiona con el modo predeterminado, "Avance rápido si es posible; de ​​lo contrario, se confirma la fusión". ¿Lo que sucede?

   Elija una respuesta.

   Git se niega porque las ramas no han divergido.

   Siempre se crea una confirmación de fusión con dos padres.

   La etiqueta de la rama avanza y no se crea ninguna confirmación de fusión.

   Cada confirmación se reescribe con una nueva ID.

   comprobar respuesta
5. Pregunta 5 de 6

   Pregunta 5 de 6Requerido

   Un colega ya sacó feature/signup-form y lo está desarrollando. Quieres que el historial de main se mantenga ordenado. ¿Cuál es la elección segura?

   Elija una respuesta.

   Rebase y empújelo con fuerza, porque un gráfico recto es más limpio.

   Elimina la rama y créala nuevamente con el mismo nombre.

   Fusione updated-main en la rama, para que sus confirmaciones conserven sus ID.

   Restablezca la rama a updated-main.

   comprobar respuesta
6. Pregunta 6 de 6

   Pregunta 6 de 6Requerido

   ¿Qué relecturas muestran que la comparación fue justa y cómo terminó?

   Elija cada respuesta que corresponda.

   Las dos copias tenían el mismo S y N antes de empezar.

   git rev-parse HEAD^{tree} imprime el mismo ID en ambas copias.

   git rev-list --parents -n 1 HEAD imprime tres ID para la copia fusionada y dos para la copia rebase.

   git rev-parse HEAD imprime la misma identificación en ambas copias.

   comprobar respuesta

Informe las dos listas de padres, los dos ID de HEAD y los dos ID de árbol. Explique por qué el resultado esperado es igual ID de árbol junto a diferentes ID de HEAD. Luego predice, sin hacerlo, qué hace una combinación predeterminada cuando el tema no tiene su propia confirmación.

• Mismo comienzo, diferente historia.
• Árboles iguales no significan historia igual.
• Fusionarse cuando otros tengan sus confirmaciones. Rebase solo los privados.

• Fusionar ramas con historial divergente (lección 18)
• Comprender las fusiones de avance rápido (lección 19)
• Rebase del trabajo no publicado en una nueva base (lección 20)
• Rebase interactivo en una GUI
• Descargar GitTree

Rebase — إعادة تأسيس; repetición — إعادة تطبيق; rama de rescate - فرع حفظ.