Reordenar, aplastar, reformular y eliminar confirmaciones locales

• Lea un plan de repetición: el paso más antiguo primero, aplicado de arriba a abajo.
• Elija la acción correcta: reformular, aplastar, arreglar o soltar.
• Avanza un paso sin romper el paso del que depende.
• Verifique las nuevas confirmaciones, los archivos y la rama de rescate luego.

Su rama private/signup-polish tiene cinco confirmaciones que existen solo en su computadora, además de la confirmación M. El árbol de trabajo está limpio y rescue/before-polish apunta a la quinta confirmación. En orden, los más antiguos primero:

Todo es local y en el plan gratuito (GitTree te pide que inicies sesión): sin cuenta de alojamiento, sin proveedor, sin Internet. Toda identidad es ficticia (ejemplo.com). Nunca ejecutes esta lección en un proyecto real y nunca reescribas confirmaciones que otras personas ya tengan.

Realice los cambios en GitTree o con los comandos nativos de Git, no ambos en la misma copia. Leer el resultado siempre es seguro. Las etiquetas del menú provienen de las propias cadenas de GitTree 2.0 y los comandos nativos se ejecutaron con Git 2.43 en copias desechables. Los pasos GitTree no se ejecutaron en macOS, Windows o Linux.

Una rebase interactiva es un plan, no un juego de clasificación. Git reproduce las confirmaciones enumeradas una por una en la base, desde la parte superior de la lista hasta la parte inferior, por lo que el paso más antiguo es el primero. Cada acción le dice a Git qué hacer con un paso:

• Pick mantiene el compromiso tal como está.
• Reword conserva su contenido y te permite escribir un mensaje nuevo.
• Squash incluye la confirmación en la confirmación mantenida que se encuentra encima y le permite escribir un mensaje combinado.
• Fixup también lo dobla, pero descarta su propio mensaje.
• Drop deja el cambio de confirmación fuera por completo.

El orden importa. Un paso que depende de otro (aquí el arreglo de etiqueta necesita el formulario de C1) debe quedar debajo de él. El editor le permitirá moverlo hacia arriba y luego la reproducción se detendrá con un conflicto. GitTree también rechaza planes que Git no puede ejecutar: un plan que descarta cada confirmación, una calabaza sin nada encima para plegarse y un mensaje vacío.

Cada confirmación reproducida obtiene una nueva ID porque su padre cambia. Sólo se reescribe esta rama; la rama de rescate se queda con los cinco viejos. Las confirmaciones que ya están en un control remoto están marcadas como "En un control remoto" y reescribirlas necesita una confirmación explícita. Esta lección nunca confirma eso.

El plan que desarrollarás convierte cinco compromisos en dos:

Comience a partir de una copia ordinaria separada del proyecto tal como lo dejó la lección 18. Deja tu gittree-features original intacto. Cree las cinco confirmaciones siguientes en una nueva rama, un archivo a la vez, y guarde cada cuerpo completo solo en el paso indicado.

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/replay-a.md — DOC_A

# Local signup review

Review the label and hint together.

docs/replay-b.md — DOC_B

# Local validation review

No address leaves this demonstration.

index.html — SIGNUP_LABEL

<!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">Fictional email address</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/revisión-temporal.md — DOC_NOISE

Temporary rehearsal note, deliberately dropped.

Abra la paleta con Comando+Mayús+P (Ctrl+Mayús+P en Ubuntu). Las acciones en una confirmación utilizan el menú contextual de esa confirmación.

1. Cree las cinco confirmaciones y la rama de rescate como se muestra en la siguiente sección, con private/signup-polish verificado y limpio. Nota M y los cinco sujetos.
2. Haga clic derecho en M, la confirmación justo debajo de los cinco, y elija Edit History → Interactive Rebase of the Commits Above…. El editor comienza con los cinco pasos privados, el más antiguo primero.
3. En Options for this rebase deje desactivadas las tres opciones, incluido Arrange fixup!, squash! and amend! commits. Usted mismo trasladará la reparación.
4. Enfoca la fila C4 y presiona Alt+ ↑ dos veces, luego enfoca C3 y presiona Alt+ ↑ una vez. El orden ahora es C1, C4, C3, C2, C5. Al presionar p, r, e, s, f o d en una fila enfocada, se configura Seleccionar, Reescribir, Editar, Aplastar, Arreglar o Soltar.
5. Establezca C1 en Reword y escriba feat: complete the local signup form en su campo de mensaje. Establezca C4 en Fixup.
6. Mantenga C3 como Pick y establezca C2 en Squash. En Squashed commits, el grupo "2 confirmaciones en documentos: explicar la validación" muestra un mensaje combinado. Reemplácelo con docs: explain signup review and validation.
7. Establezca C5 en Drop. Lea cada fila y el mensaje combinado una vez más. No hay nada marcado como "En un control remoto", por lo que no se necesita confirmación.
8. Elija Start Rebase una vez y espere. Si se detiene, utilice el banner para continuar; No empieces todo el plan de nuevo.
9. Verifique dos confirmaciones nuevas, la etiqueta corregida en la página, ambos documentos y ninguna nota temporal. Mantenga rescue/before-polish y deje limpio el árbol de trabajo.

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.

Construya las cinco confirmaciones en una nueva rama, guardando cada cuerpo completo en su paso:

git switch --create private/signup-polish

Guarde REGÍSTRESE como index.html y luego:

git add -- index.html
git commit --quiet -m "feat: add signup draft"

Guarde DOC_A como docs/replay-a.md y luego:

git add -- docs/replay-a.md
git commit --quiet -m "docs: explain signup review"

Guarde DOC_B como docs/replay-b.md y luego:

git add -- docs/replay-b.md
git commit --quiet -m "docs: explain validation"

Guarde SIGNUP_LABEL como index.html y luego:

git add -- index.html
git commit --quiet -m "fixup! feat: add signup draft"

Guarde DOC_NOISE como docs/temporary-review.md y luego:

git add -- docs/temporary-review.md
git commit --quiet -m "chore: temporary note"

Proteja el consejo anterior y enumere el rango, el más antiguo primero:

git branch rescue/before-polish
BASE_SHA="$(git rev-parse HEAD~5)"
git log --reverse --format=%s "$BASE_SHA"..HEAD

Ahora inicie la rebase interactiva (-i es la forma abreviada de --interactive). Git abre su editor con la lista de tareas pendientes (sus ID serán diferentes):

git rebase --interactive --no-autosquash --no-update-refs --no-autostash "$BASE_SHA"

pick 1a2b3c4 feat: add signup draft
pick 2b3c4d5 docs: explain signup review
pick 3c4d5e6 docs: explain validation
pick 4d5e6f7 fixup! feat: add signup draft
pick 5e6f708 chore: temporary note

Vuelva a escribir las cinco líneas en el plan, manteniendo el ID de cada línea y guarde:

reword 1a2b3c4 feat: add signup draft
fixup 4d5e6f7 fixup! feat: add signup draft
pick 3c4d5e6 docs: explain validation
squash 2b3c4d5 docs: explain signup review
drop 5e6f708 chore: temporary note

Luego, Git abre el editor dos veces más. Para redactar nuevamente, reemplace el mensaje con feat: complete the local signup form. Para la calabaza, muestra ambos mensajes; reemplácelos con una línea, docs: explain signup review and validation. Comprueba el resultado:

git rev-list --count "$BASE_SHA"..HEAD
git log --reverse --format=%s "$BASE_SHA"..HEAD
git status --short

2
feat: complete the local signup form
docs: explain signup review and validation

El estado está vacío. index.html es SIGNUP_LABEL, ambos documentos existen y docs/temporary-review.md no.

Si pones una calabaza en la primera línea, Git se detiene inmediatamente con error: cannot 'squash' without a previous commit. Arregle la lista con git rebase --edit-todo y git rebase --continue, o déjela con git rebase --abort. Con --autosquash Git hace el movimiento y la acción para fixup! se confirma por usted; esta lección lo desactiva para mostrar el plan.

Where you end: dos confirmaciones reescritas arriba de M, "hazaña: completar el formulario de registro local" y "docs: explicar la revisión y validación del registro". La página tiene la etiqueta corregida, ambos documentos están ahí y la nota temporal no. La rama de rescate conserva los cinco compromisos antiguos y el árbol de trabajo está limpio.

• Usando Drop para ocultar una confirmación que puedas necesitar. El cambio no está en absoluto en la nueva historia.
• Al mover una solución por encima del compromiso, se soluciona.
• Aplastando el primer escalón, que no tiene nada encima para doblarse.
• Comenzar el plan nuevamente una vez finalizado, en lugar de verificar el resultado primero.

Antes de comenzar, Cancel deja la rama como está. Si GitTree dice que la rama cambió desde que se abrió el editor, cierre el editor y ábralo nuevamente. Si la rebase se detiene, solucione el conflicto o el mensaje y continúe desde el banner, o cancelelo deliberadamente. Una vez finalizado, compárelo con rescue/before-polish antes de intentar restaurar algo.

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

   En la lista de tareas pendientes de una rebase interactiva, ¿qué confirmación se reproduce primero?

   Elija una respuesta.

   La confirmación con el primer mensaje alfabéticamente.

   La confirmación más antigua, en la parte superior de la lista.

   La confirmación que editaste por última vez.

   La confirmación más reciente, como en git log.

   comprobar respuesta
2. Pregunta 2 de 6

   Pregunta 2 de 6

   ¿Cuál de estos planes no puede funcionar?

   Elija cada respuesta que corresponda.

   Eliminando todos los compromisos en el rango.

   Al mover una solución por encima del compromiso, se soluciona.

   Aplasta en el primer paso.

   Reformule el primer paso.

   comprobar respuesta
3. Pregunta 3 de 6

   Pregunta 3 de 6Requerido

   El plan es: reformular C1, arreglar C4, elegir C3, aplastar C2, soltar C5. Después de ejecutarse, ¿cuántas confirmaciones hay por encima de M y adónde va el archivo de la nota temporal?

   Elija una respuesta.

   Dos confirmaciones; El archivo de la nota permanece porque la confirmación anterior está en la rama de rescate.

   Tres confirmaciones; la nota pasa a la última.

   Cinco confirmaciones; sólo cambian los mensajes.

   Dos confirmaciones; El archivo de la nota temporal no está en el nuevo historial.

   comprobar respuesta
4. Pregunta 4 de 6

   Pregunta 4 de 6

   Cambia la entrada: dejas C5 como Seleccionar en lugar de Soltar. ¿Qué es diferente?

   Elija una respuesta.

   GitTree le pide que confirme una reescritura de las confirmaciones publicadas.

   Resultan tres confirmaciones y docs/temporary-review.md está en los archivos finales.

   Resultan dos confirmaciones y la nota se oculta de la lista de archivos.

   El equipo de rescate se traslada a la nueva punta.

   comprobar respuesta
5. Pregunta 5 de 6

   Pregunta 5 de 6Requerido

   Estableces el paso 1 en Squash y GitTree se niega a comenzar: "El paso 1 se aplasta en la nada: muévelo debajo de una confirmación mantenida". ¿Qué significa y qué haces?

   Elija una respuesta.

   Nada por encima del paso 1 puede recibirlo. Muévalo debajo de una confirmación mantenida o configúrelo en Seleccionar.

   Git es demasiado viejo. Actualiza Git.

   Las confirmaciones se publican. Confirma la reescritura.

   La rama cambió desde que se abrió el editor. Cerrar y volver a abrir.

   comprobar respuesta
6. Pregunta 6 de 6

   Pregunta 6 de 6Requerido

   ¿Qué retrolecturas prueban que el resultado es el que el plan debía producir?

   Elija cada respuesta que corresponda.

   git rev-parse HEAD es igual a git rev-parse rescate/antes de polaco.

   git log --reverse --format=%s BASE..HEAD enumera los dos nuevos temas.

   git status --short está vacío y docs/temporary-review.md no existe.

   git rev-list --count BASE..HEAD imprime 2.

   comprobar respuesta

Explica el plan C1, C4, C3, C2, C5 y los dos mensajes que sobreviven. Verifique el rango antiguo 5, el nuevo rango 2, los archivos esperados y ninguna nota. Luego predice, sin ejecutarlo, por qué mover C4 por encima de C1 o aplastar el paso 1 no puede funcionar.

• Un plan de reproducción tiene un orden y dependencias.
• Squash guarda ambos mensajes para que puedas combinarlos; la reparación descarta la suya.
• Drop elimina el cambio en sí, por lo que solo suelta ruido real.

• Rebase del trabajo no publicado en una nueva base (lección 20)
• Fusionar versus reorganizar: elegir con un gráfico (lección 21)
• Rebase interactivo en una GUI
• Descargar GitTree

Reformular: إعادة صياغة; calabaza—ضمّ; reparación — ضمّ مع تجاهل الرسالة; soltar—إسقاط; plan de repetición — خطة إعادة تطبيق.