Ribasare il lavoro inedito su una nuova base

• Identificare l'esatto intervallo di riproduzione privata.
• Proteggi la vecchia cronologia impegnata prima della riproduzione.
• Riconoscere le identità di commit ricreate.
• Verifica l'albero principale e l'albero risultante completo.

Inizia da una copia separata del risultato della lezione 18 (principale è l'unione M, pulito): la funzionalità/modulo di iscrizione dell'argomento privato contiene un commit S, il principale aggiornato contiene un commit N diverso, entrambi su M, e anche il salvataggio/iscrizione-prima-rebase punta a S. L'argomento è stato estratto, pulito e non pubblicato.

Il video è stato registrato con Git 2.52.0 e GitTree 2.0 su Ubuntu 24.04: il topic privato e la base più recente sono stati costruiti nel terminale; il rebase, la sua finestra di dialogo e i controlli del risultato sono stati eseguiti nell'app; il risultato è stato riletto nel terminale. La riproduzione nativa riportata di seguito è stata eseguita in una copia usa e getta e ha fornito lo stesso risultato. Non è stato eseguito nulla su macOS o Windows e Ubuntu è l'unico sistema Linux registrato. Il Git floor di origine di GitTree è 2.39.0.

GitTree ti chiede di accedere; il piano gratuito copre quindi ogni passaggio qui. Non è necessario alcun account fornitore, Pro/prova, credenziale API o servizio Internet. Un'origine nuda locale non è GitLab o CI. Tutte le identità utilizzano example.com; non eseguire mai questa lezione all'interno di un checkout di origine.

Effettua mutazioni tramite GitTree o il percorso nativo su input identici, non entrambi consecutivamente. È possibile seguire anche la verifica di sola lettura. Qualsiasi preparazione descritta come lavoro terminale è etichettata come preparazione nativa, mai come funzionalità inventata dell'app.

Rebase seleziona commit univoci per l'argomento corrente e ne riproduce le modifiche su una nuova base. Non sposta i vecchi impegni stessi; crea nuovi commit con nuovi genitori e solitamente nuovi ID.

Il ramo di origine deve essere il ramo corrente previsto. In questo dispositivo S aggiunge la registrazione e N aggiunge un documento diverso, quindi la riproduzione è priva di conflitti, ma ciò non rende sicuri i rebase arbitrari.

La cronologia pubblicata è un confine di coordinamento. Questi commit sono intenzionalmente privati; non ribasare la funzionalità dei prezzi già pubblicata semplicemente per rendere il suo grafico chiaro. Un riferimento di salvataggio protegge gli antenati impegnati, non il testo non salvato.

Caratteristica e avanzamento TESTA S→S′; indice/opera diventano l'albero combinato. N/principale aggiornato, S di salvataggio e principale/M originale rimangono fissi. Nessuna mutazione del server o push automatico.

Iniziare da una copia ordinaria separata del progetto così come lo ha lasciato la lezione 18 (la principale è la fusione M). Le funzionalità originali di Gittree rimangono preservate; non eseguire questo scenario nell'originale o nel checkout di origine. Quindi eseguire la preparazione esatta di seguito. La firma demo locale del repository è disattivata e l'identità è GitTree Demo <demo@example.com>.

Risparmia solo nella fase denominata di seguito. Questi sono corpi UTF-8/LF completi con un ritorno a capo finale; non incollare mai le recinzioni Markdown. I file eseguibili non modificati ereditano l'input denominato. Le versioni in varianti separate non devono sovrascrivere l'originale.

index.html — ISCRIVITI

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

Tavolozza: Comando+Maiusc+P (Ctrl+Maiusc+P su Ubuntu); digitare il comando con il nome esatto e selezionarlo. Le azioni di riferimento con nome utilizzano il menu contestuale di quella riga, non una scorciatoia della tavolozza senza argomenti.

1. Preparare la divergenza esatta e il ramo di salvataggio utilizzando la configurazione nativa etichettata di seguito; nessun ramo pubblicato viene riscritto.
2. Nell'app conferma la funzionalità/il modulo di iscrizione verificato, pulito e non pubblicato; ispezionare S e N.
3. Fare clic con il tasto destro su updated-main nel grafico → Rebase feature/signup-form onto updated-main; la finestra di dialogo nomina il ramo corrente e la destinazione.
4. Leggi Options for this rebase. Lascia Stash local changes and put them back e Move the branches that point into these commits disattivati. La finestra di dialogo dice che la vecchia funzionalità/modulo di iscrizione è mantenuta in refs/ogt/trash.
5. Scegli Rebase feature/signup-form una volta; attendere l'avviso che il rebase è terminato. Se si ferma, mantieni lo stato operativo anziché fare nuovamente clic.
6. Ispeziona S′ genitore N e soggetto. Confronta gli ID vecchi/nuovi effettivi, non le etichette del modello come output del terminale.
7. Ispeziona SIGNUP e DOC_MERGE completi nell'albero risultante; il ramo di soccorso punta ancora alla vecchia S.
8. Verificare lo stato pulito e nessuna operazione di rebase; lascia stare il main/M originale e tutti i riferimenti del server.

Per ogni commit ordinario: Summary è l'oggetto indicato; Descrizione vuota; Modifica commit precedente, Salta hook, Aggiungi autore firmato, Autore diverso, Push dopo commit e Consenti commit vuoto disattivato; nessun coautore. Metti in stage solo i file nominati, quindi applica le modifiche a N file una volta (File per uno) o Comando+Invio come alternativa. Aspetta il risultato reale. Una lezione che modifica esplicitamente cambia solo l'opzione dichiarata.

In una copia separata e pulita della lezione 18/M, crea l'argomento privato:

git switch --create feature/signup-form

Inserisci il file SIGNUP salvato su index.html (il video ha salvato i file della lezione in ~/Downloads e utilizza cp ~/Downloads/SIGNUP.html index.html), quindi:

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"

Nella sezione principale aggiornata inserisci DOC_MERGE in docs/integration-note.md (cp ~/Downloads/DOC_MERGE.md docs/integration-note.md), quindi:

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

BASE_SHA è il genitore M misurato prima del commit dell'iscrizione privata. Sia il topic che il main aggiornato ora hanno un commit indipendente; Rescue/Signup-Before-Rebase mantiene il vecchio argomento. Non viene pubblicato nulla di questo argomento.

Alternativa al replay nativo:

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

Soggetto osservato:

feat: add the local signup demonstration

La HEAD effettiva differisce dalla S salvata; HEAD^ è uguale a aggiornato-principale/N. Rimangono sia il documento indipendente che l'esatto organismo di SIGNUP; lo stato breve è silenzioso. Interrompi su un input pubblicato/sporco inaspettato invece di aggiungere opzioni di forzatura. Per la variante del conflitto, vedere la lezione 23; non considerare un rebase interrotto come già terminato.

Where you end: punti funzione/modulo di iscrizione S′, genitore N, con iscrizione più DOC_MERGE; la vecchia S sopravvive in salvataggio/registrazione prima del rebase. Nessuna operazione attiva, pulizia; main/M e server invariati.

• Supponendo che un grafico lineare significhi che il vecchio ID di commit è sopravvissuto.
• Trattare il riquadro alternativo come il checkpoint originale.
• Ripetere una mutazione completata dopo il successo dell'app.

Prima del replay il ramo di salvataggio conserva S. Se l'operazione si interrompe, ispeziona il banner e risolvi o annulla esplicitamente; un rebase completato non viene interrotto da rebase --abort. Non dare mai per scontato che Native Replay abbia scritto un diario GitTree.

Rispondi a ciascuna domanda, quindi leggi il motivo. Le domande contrassegnate come "Obbligatorio" contano ai fini del completamento della lezione.

1. Domanda 1 di 6

   Domanda 1 di 6

   Cosa viene riprodotto?

   Scegli una risposta.

   Ogni file del repository alla cieca

   Il server remoto

   Cambiamenti di argomento privato

   Controlla la risposta
2. Domanda 2 di 6

   Domanda 2 di 6

   Cosa deve essere controllato?

   Scegli ogni risposta applicabile.

   Ramo attuale e destinazione

   Campo privato e rif. di salvataggio

   Solo colore del grafico

   Controlla la risposta
3. Domanda 3 di 6

   Domanda 3 di 6Obbligatorio

   S riprodotto su N: genitore?

   Scegli una risposta.

   Il commit principale aggiornato N

   S come genitore

   Solo vecchia M

   Controlla la risposta
4. Domanda 4 di 6

   Domanda 4 di 6Obbligatorio

   Cambia input: la stessa linea dell'eroe è cambiata su entrambi i lati.

   Scegli una risposta.

   Sempre senza conflitti

   Scarta automaticamente un lato

   Un conflitto potrebbe interrompere la riproduzione

   Controlla la risposta
5. Domanda 5 di 6

   Domanda 5 di 6

   Può --abort annullare un rebase già terminato?

   Scegli una risposta.

   Annulla i push del server

   Sempre

   Non esiste alcuna operazione attiva

   Controlla la risposta
6. Domanda 6 di 6

   Domanda 6 di 6Obbligatorio

   Cosa dimostra questo risultato?

   Scegli ogni risposta applicabile.

   Nuovo ID e N. genitore

   Vecchia S salvata, file completi puliti

   Solo messaggio invariato

   Controlla la risposta

Dimostrare che il nuovo HEAD è diverso dal salvataggio, che il suo genitore è uguale a N e che i byte completi di registrazione/documento concordano. Prevedi i conflitti se entrambe le parti cambiano la stessa linea di eroi, in una copia separata della lezione 23.

• Rebase ricrea i commit.
• Scegli il ramo corrente e la destinazione in modo esplicito.
• La storia privata e l'ambito del recupero sono importanti.

• Unire rami con cronologia divergente (lezione 18)
• Comprendere le unioni con avanzamento rapido (lezione 19)
• Crea un ramo di funzionalità e ritira solo il riferimento usa e getta (lezione 9)
• Scarica GitTree

Rebase — إعادة تأسيس; ripetere: إعادة تطبيق; rif. salvataggio — مرجع حفظ.