Vai al contenuto
GitTree

Lezione 11 · Lavoro quotidiano

Recupera la modifica di un compagno di squadra senza sostituire la tua pagina

Ricevi il vero commit del footer di Leo mantenendo invariati il main, l'indice e la pagina di lavoro originale. Quindi ispeziona l'eliminazione dei riferimenti obsoleti in un replay separato in modo che l'eliminazione del server non venga confusa con la pulizia locale.

Avanzamenti salvati in questo browser.

La riproduzione carica il video da YouTube (modalità ottimizzata per la privacy).

Narrazione in inglese · English and Arabic didascalie

Apri la pagina del videoGuarda su YouTube

Cosa imparerai

  • Spiega perché un riferimento di tracciamento remoto recuperato può avanzare mentre main no.
  • Confronta il piè di pagina recuperato senza verificarlo o integrarlo.
  • Prevedi il comportamento di recupero quando la pagina di lavoro presenta una modifica locale sovrapposta.
  • Distinguere l'eliminazione di un riferimento locale obsoleto dall'eliminazione di un server o di un ramo locale.

Prima di iniziare

Inizia da dove è terminata la lezione 10: main/H6 originale estratto, sei commit tra cui docs/remotes.md, clean, tracciamento origin/main/H6. L'origine nuda locale separata ha solo main/H6. Funzionalità/carte-prezzi/F1 rimane locale, senza upstream o pubblicazione. Mantieni disattivato il recupero dello sfondo della demo (repo.autoFetchInterval = 0) per acquisire un prima/dopo autentico. Non utilizzare il clone supplementare della lezione 4.

Utilizzare un nuovo fratello gittree-features-leo per il compagno di squadra; interrompere se la destinazione esiste già. Tutti i repository sono copie usa e getta di GitTree Funzionalità, al di fuori di ogni checkout della fonte. Il video è stato registrato con Git 2.52.0 e GitTree 2.0 su Ubuntu 24.04: commit e push di Leo, preparazione della copia stale-ref e controlli eseguiti nel terminale; il recupero, il grafico, il confronto dei riferimenti, la visualizzazione dei file e la prune remota sono stati eseguiti nell'app. Non è stato eseguito nulla su macOS o Windows e Ubuntu è l'unico sistema Linux registrato. Il piano di origine di GitTree è Git 2.39.0. Per questo trasporto Git locale non sono necessarie credenziali di provider, Pro/prova o API.

Concetto

Fetch ottiene oggetti e aggiorna la conoscenza recuperata. Qui il main del server avanza all'H7 di Leo, ma l'origine/main dell'originale rimane H6 fino al recupero. Un conteggio zero-behind rispetto a un'origine/principale obsoleto non è una prova che il server sia invariato.

Dopo il recupero, i nomi origine/principale H7 mentre main locale e HEAD rimangono H6. Anche l'indice e la pagina di lavoro rimangono H6. Leggere le differenze nel piè di pagina è un'ispezione, non un pull, un checkout, un'unione o un rebase. "Dietro uno" misura l'ascendenza, non quanti file o righe differiscono.

Pull is fetch plus a second step. git pull esegue un recupero e quindi integra ciò che è arrivato nel tuo ramo corrente (un avanzamento veloce, un'unione o un rebase). Il recupero da solo si interrompe dopo la prima metà, motivo per cui non potrà mai modificare i tuoi file. La lezione 12 sceglie di proposito il secondo passaggio.

Pruning rimuove i riferimenti di monitoraggio remoto il cui ramo del server corrispondente è scomparso, in base alle regole di recupero/refspec. Non elimina di per sé quel ramo del server, non cancella un ramo locale o rimuove ogni tag. La richiesta Fetch All dell'origine abilita già l'eliminazione; il suo equivalente nativo riportato di seguito include quindi --prune. Prune Remote è un'azione denominata-remota separata, dimostrata solo in una copia di riferimento obsoleto preparata separata.

Effetti dello stato

PassoTESTA/principale originaleIndice/operaorigine/principaleServer principale separato
IngressoH6Pagina H6H6H6
Leo si impegna e spinge dal suo cloneH6InvariatoH6, ora stantioH7
Recupera tutto originaleH6InvariatoH7H7
Ispezionare il differenzialeH6InvariatoH7H7

Non viene aggiunto alcun commit del notebook originale: la vera operazione del progetto è l'aggiornamento del riferimento recuperato. La caratteristica locale punta ancora alla F1.

Input di file completi

Solo nel clone di Leo, sostituisci index.html con il primo corpo completo. Il suo argomento è docs: add Leo's review reminder; autore/committente Leo Okafor <leo@example.com>. Il corpo dell'input modificato è una modifica di lavoro separata della copia originale, non un secondo commit canonico.

Estratto del file · html
<!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">
    <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>

Replay dirty-fetch separato: HTML-DIRTY-FETCH

Questo corpo completo è solo per il replay separato con input modificato, mai per l'originale canonico.

Estratto del file · html
<!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">
    <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">Inspect the update before integrating it.</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.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

Tra GitTree

  1. Apri la scheda principale originale; ispezionare l'identità del repository e lo stato pulito. Conferma che l'override del recupero in background rimane0. Non modificare il checkout dell'origine né recuperare automaticamente prima che venga acquisito lo stato precedente.
  2. Prepara il clone di Leo e il commit esatto del piè di pagina con T1 di seguito, etichettato esplicitamente come native teammate preparation. La sua spinta aggiorna il server nudo locale, non il record recuperato dell'originale. Non è coinvolto alcun account ospitato o risposta simulata del provider.
  3. Prima di recuperare, esegui T2. Main e origin/main concordano ancora in H6, anche se la ricerca diretta del server nomina un SHA effettivo diverso. La pagina funzionante ha ancora il vecchio piè di pagina.
  4. Apri la tavolozza con Command+Shift+P (Ctrl+Shift+P su Ubuntu) e scegli Fetch All una volta; Comando+Maiusc+F (Ctrl+Maiusc+F) è la scorciatoia. Attendere l'operazione reale e il risultato; non fare clic su Tira. Con un'origine, fare clic con il pulsante destro del mouse su origin → Fetch Remote è un equivalente, non un secondo recupero richiesto (non è stato filmato).
  5. Nel grafico seleziona il commit appena recuperato, docs: add Leo's review reminder, e controlla l'oggetto reale e i metadati Leo. L'etichetta locale main/HEAD rimane al suo commit precedente. La selezione di una riga del grafico non equivale al pagamento.
  6. La tavolozza Compare References… si apre Compare References. Old side = principale; New side = origine/principale; What to compare = The two endpoints; scegli Compare. Aspettatevi solo index.html, con l'esatto promemoria aggiunto al piè di pagina. Non utilizzare la terminologia di tipo merge-base/log-set per questo confronto tra alberi endpoint.
  7. Show Files (Comando+Maiusc+E, Ctrl+Maiusc+E su Ubuntu); seleziona working index.html e Invio. Il suo piè di pagina è ancora l'originale. Scegli Back to Graph, quindi la tavolozza Show Working Changes: gli elenchi gestiti/non gestiti rimangono vuoti. Non è richiesto alcun salvataggio locale, commit o integrazione.
  8. Termina su main con sei commit, origin/main a sette, count0/1 e clean work/index. Mantieni la funzionalità locale non pubblicata. Non “aggiustare” la situazione dietro forzando una spinta.
  9. Separate stale-ref replay only: prepara B come descritto di seguito, non l'originale. Esegui prima un ciclo di prova delle prugne autoctone. Apri B da New Tab (Ctrl+T) con la sua riga Open gittree-features-prune sotto Repository recenti. Nella scheda di B, fai clic con il pulsante destro del mouse sul nome origin nel pannello laterale → Prune Remote. L'app invia direttamente l'azione; non è stata inventata alcuna finestra di anteprima o di conferma. Osservare la scomparsa di origin/practice/stale mentre il keep-stale locale e tutti i byte funzionanti rimangono.

Gli accordi del tasto Comando provengono dalla mappa dei tasti dell'app; i moduli Ctrl erano quelli utilizzati su Ubuntu. La preparazione del compagno di squadra e del server è un lavoro nativo nel terminale, non un progetto ospitato creato dall'app.

Nel terminale

Tutti i comandi seguenti iniziano con original isolated gittree-features a meno che non sia esplicitamente un comando -C. I comandi nativi originali-fetch sono alternative all'azione dell'app, non mutazioni da ripetere dopo di essa.

T1: vera preparazione del compagno di squadra

Command · bash
git clone --quiet --branch main "$(git remote get-url origin)" ../gittree-features-leo
git -C ../gittree-features-leo config user.name "Leo Okafor"
git -C ../gittree-features-leo config user.email leo@example.com
git -C ../gittree-features-leo config commit.gpgsign false

Il nuovo clone esiste, il main viene estratto e viene modificata solo la sua identità locale. In quel clone, cambia solo la riga a piè di pagina in modo che l'intero file sia uguale a HTML-LEO-FOOTER (il video lo fa con un comando sed; il salvataggio del corpo completo in un editor restituisce lo stesso file), quindi:

Command · bash
git -C ../gittree-features-leo add -- index.html
git -C ../gittree-features-leo commit --quiet -m "docs: add Leo's review reminder"
git -C ../gittree-features-leo push --quiet origin main

Tutto è riuscito in silenzio. Questa è una vera spinta Git verso la nuda origine locale usa e getta; nessun account Internet o dato di produzione è stato toccato.

T2: distingue la conoscenza locale obsoleta dallo stato del server

Command · bash
git rev-list --left-right --count main...origin/main
git rev-parse refs/heads/main
git rev-parse refs/remotes/origin/main
git ls-remote --heads origin refs/heads/main

Il conteggio stampato:

Uscita
0	0

I successivi due output SHA sono identità H6 uguali; ls-remote stampa il diverso SHA H7 effettivo più refs/heads/main. Gli SHA variano in base ai metadati di commit, quindi qui non viene stampato alcun hash falso fisso. Questa query diretta al server non aggiorna origin/main.

T3: recupera senza integrazione e verifica

Command · bash
git fetch --all --prune --quiet

Osservato: uscita 0, nessuno stdout. La fonte di GitTree abilita l'eliminazione di questa richiesta; il comando rispecchia quella scelta.

Command · bash
git symbolic-ref --short HEAD
git rev-list --count main
git rev-list --count origin/main
git rev-list --left-right --count main...origin/main
git log -1 --format="%s%n%an <%ae>%n%cn <%ce>" origin/main
git diff --name-only main origin/main
git status --short

Output prima dello stato finale, con i risultati dei metadati su tre righe raggruppati:

Uscita
main
6
7
0	1
docs: add Leo's review reminder
Leo Okafor <leo@example.com>
Leo Okafor <leo@example.com>
index.html

Lo stato breve finale è vuoto exit 0. L'SHA principale, il file index.html completo nell'indice e i byte completi del disco sono stati confrontati prima/dopo e sono rimasti identici. Né il recupero né l'ispezione del grafico hanno verificato H7.

Command · bash
git diff main origin/main -- index.html

Differenza osservata completa:

Uscita
diff --git a/index.html b/index.html
index eebd082..1e4cfde 100644
--- a/index.html
+++ b/index.html
@@ -34,7 +34,7 @@
       </div>
     </section>
   </main>
-  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
+  <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>

T4: input modificato: pagina sporca locale

Solo in una copia separata dello stesso progetto dell'originale di precaricamento, salva l'intero HTML-DIRTY-FETCH senza gestione temporanea. Il server H7 di Leo esiste già:

Command · bash
git fetch --all --prune --quiet
git status --short
git show :index.html
git rev-list --left-right --count main...origin/main

Il recupero ha esito positivo; stato:

Uscita
 M index.html

L'output completo di git show rimane il vecchio file registrato/indice, non l'edizione funzionante. I conteggi finali sono 0/1. Il file del disco di lavoro rimane exactly HTML-DIRTY-FETCH. Un nome file sovrapposto non crea di per sé un conflitto di recupero; l'integrazione successiva ha presupposti diversi. Il video confronta l'indice e il file di lavoro con grep -n 'hero-copy\|<footer>' su ciascuno invece di stampare l'intero file; il controllo del replay ha confermato che il file di lavoro è uguale a HTML-DIRTY-FETCH.

T5: riferimento di tracciamento remoto obsoleto, B separato

Crea un originale B isolato dello stesso progetto e una destinazione B bare separata con il server principale/H7. Punta B only a quella destinazione utilizzando l'URL del file misurato. Non effettuare il retargeting A.

Dalla cartella demo originale, prepara due nuove destinazioni sorelle inesistenti. Questi comandi clonano lo stesso progetto in B e nel proprio server, senza mai effettuare il retargeting di A:

Command · bash
git clone --quiet --bare --single-branch --branch main --no-local ../gittree-features-origin.git ../gittree-features-prune-origin.git
git clone --quiet --single-branch --branch main --no-local . ../gittree-features-prune
PRUNE_URL="$(node --input-type=module -e "import path from 'node:path'; import {pathToFileURL} from 'node:url'; console.log(pathToFileURL(path.resolve('../gittree-features-prune-origin.git')).href);")"
git -C ../gittree-features-prune remote set-url origin "$PRUNE_URL"
git -C ../gittree-features-prune config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
git --git-dir=../gittree-features-prune-origin.git branch practice/stale main
git -C ../gittree-features-prune fetch --prune --quiet origin
git -C ../gittree-features-prune branch keep-stale origin/practice/stale
git --git-dir=../gittree-features-prune-origin.git branch --delete --quiet practice/stale

Il clone B a ramo singolo inizialmente recupera solo il main. La sua assegnazione esplicita remote.origin.fetch ripristina la mappatura dei rami jolly della demo originale in modo che practice/stale possa essere recuperato; cambia solo B. Arresta su qualsiasi comando di preparazione non riuscito. Imposta l'intervallo di recupero in background specifico del repository di B su 0 prima dell'acquisizione effettiva dell'app. Il ramo del server usa e getta è ora assente, mentre B ha ancora il record recuperato e un ramo locale separato che mantiene obsoleto. I seguenti comandi prendono di mira esplicitamente B:

Command · bash
git -C ../gittree-features-prune remote prune --dry-run origin
git -C ../gittree-features-prune remote prune origin
git -C ../gittree-features-prune for-each-ref --format='%(refname)' refs/remotes/origin/practice/stale
git -C ../gittree-features-prune show-ref --verify --quiet refs/heads/keep-stale

Osservato preview excerpt dopo la riga URL variabile:

Uscita
 * [would prune] origin/practice/stale

Osservato execution excerpt:

Uscita
 * [pruned] origin/practice/stale

Il for-each-ref è vuoto exit 0; show-ref è silenzioso exit 0, dimostrando che il keep-stale locale esiste ancora. L'SHA principale e la pagina di lavoro di B rimangono invariati; il server principale rimane H7. Le trascrizioni native complete includono l'origine della potatura e l'URL del file misurato; quei percorsi specifici della macchina non vengono fabbricati qui.

Non inserire un normale Fetch All tra la preparazione stantio-ref e Prune Remote: Fetch All già prune, senza lasciare alcun candidato stantio per la dimostrazione separata.

Risultato

Where you end: main/H6 originale è ancora estratto con sei commit e il vecchio piè di pagina; origin/main/H7 registra il settimo commit di Leo; server main/H7 invariato dal recupero; tracce principali origine/principale ed è una dietro. Indice/lavoro pulito; funzionalità/schede-prezzi/F1 ancora locale/non pubblicato. I rami B/C, il testo sporco e la preparazione alla potatura rimangono fuori da A. Non c'è alcun commit aggiuntivo di docs/fetch-and-prune.md.

Errori comuni

  • Chiamando il pre-fetch0/0 conta la verità del server corrente.
  • Mi aspetto che il piè di pagina recuperato sostituisca automaticamente la pagina di lavoro.
  • Utilizzo di Pull o checkout per far sì che una registrazione di recupero sembri riuscita.
  • Aspettarsi che una pagina sporca venga scartata o messa in conflitto semplicemente tramite il recupero.
  • Interpretare prune come l'eliminazione del repository remoto o il keep-stale locale.

Se qualcosa va storto

Una cartella mancante, un URL errato o un errore di autorizzazione significa controllare l'origine prevista e l'errore effettivo, non reimpostare la cronologia o sovrascrivere la destinazione. Il rifiuto della rete/aiutante/fiducia non è prova di zero aggiornamenti; registrare la sua build/messaggio effettivo e risolvere solo la causa dichiarata. La modalità limitata può rifiutare il trasporto; fidatevi solo del laboratorio usa e getta recensito, mai di un deposito casuale per superare il film.

Se l'originale principale è stato spostato o il piè di pagina è cambiato, fermati e controlla se è stato eseguito il pull, il checkout o una modifica esterna. Non effettuare un hard reset per mascherare la causa. Preserva lo stato imprevisto prima di preparare un nuovo checkpoint demo.

Se non rimane alcun riferimento obsoleto, controlla se un precedente Fetch All lo ha già eliminato. Ripreparare B; non inventare una riga che scompare o eliminare un ramo utile del server.

Controlla la tua comprensione

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

    Leo ha spinto H7, ma non hai recuperato. Quale potrebbe essere il nome dell'origine/principale?

    Scegli una risposta.

  2. Domanda 2 di 6

    Quali osservazioni appartengono al risultato canonico del recupero?

    Scegli ogni risposta applicabile.

  3. Domanda 3 di 6

    Dopo il recupero, main has6 e origin/main7 con H6 come genitore di H7. Qual è il conteggio principale...origine/principale?

    Scegli una risposta.

  4. Domanda 4 di 6

    Modifica l'input: salva HTML-DIRTY-FETCH senza staging, quindi recupera H7. Che succede?

    Scegli una risposta.

  5. Domanda 5 di 6

    Il ramo del server di B è stato eliminato, ma B ha origini/pratica/stale e locale keep-stale. Cosa rimuove la potatura?

    Scegli una risposta.

  6. Domanda 6 di 6

    Quali controlli sono necessari insieme?

    Scegli ogni risposta applicabile.

0 di 6 corretto

Hai risposto correttamente a tutte le domande richieste.

Controllato in questo browser.

Pratica

Prevedi le due versioni della pagina originale dopo il recupero: indice e lavoro rimangono entrambi H6, mentre il nuovo albero remoto contiene il piè di pagina di Leo. Nella riproduzione sporca separata, verificare che il testo completo del disco sopravviva e che non venga creato alcun conflitto. In B, spiega perché keep-stale sopravvive alla potatura. Termina solo l'originale al checkpoint clean0/1.

La tua conferma: il sito non può vedere il tuo computer.

Per completare la lezione rispondere correttamente alle domande richieste e confermare l'esercizio pratico.

Riepilogo

  • Fetch aggiorna la conoscenza locale senza integrare il ramo.
  • Lo stato pulito non significa che il telecomando sia aggiornato.
  • L'eliminazione dei riferimenti di tracciamento locale è diversa dall'eliminazione dei rami locali o del server.

Termini del glossario introdotti

Recupera — sì; prugna secca: تشذيب; riferimento di tracciamento remoto obsoleto — مرجع تتبُّع بعيد قديم; dietro: متأخر; confronto degli endpoint: مقارنة الطرفين.

Trascrizione video

La narrazione del video, spunto per spunto.

Mostra la trascrizione
  1. Ricevi l'aggiornamento senza sostituendo la pagina corrente.
  2. Mantieni il recupero dello sfondo disattivato per questa ripresa prima e dopo.
  3. Prepara il clone separato di Leo con un'identità locale fittizia.
  4. Leo registra e spinge il piè di pagina richiamo all'origine locale.
  5. Il server si è spostato mentre il tuo il record recuperato è rimasto indietro.
  6. Questi conteggi utilizzano il recupero locale ref, non uno snapshot del server live.
  7. Quale arbitro si sposterà e quale versione del file rimarrà?
  8. Recupera tutti i telecomandi configurati; qui c'è solo l'origine.
  9. Attendi prima il risultato di Git trattando l'aggiornamento come ricevuto.
  10. Selezione del commit di Leo non lo controlla.
  11. Confronta main con quello recuperato albero senza spostare nessuno dei due rif.
  12. L'albero recuperato ha il promemoria; la tua pagina di lavoro continua a non farlo.
  13. Il file di lavoro originale mantiene il suo vecchio piè di pagina.
  14. I cambiamenti lavorativi puliti no significa che la tua filiale è aggiornata.
  15. Verifica sei commit locali, sette commit recuperati e uno indietro.
  16. Recupero della conoscenza aggiornata senza integrando il contenuto del file.
  17. Una modifica locale nello stesso il file sopravvive a questo recupero.
  18. Il ramo del server è già andato prima di questo esempio di potatura.
  19. Visualizza l'anteprima del monitoraggio obsoleto ref prima di rimuoverlo.
  20. Rimuovere il monitoraggio locale obsoleto ref, non il ramo di soccorso locale.
  21. La filiale locale e la pagina di lavoro rimane intatta.
  22. Potrebbe essere già stato effettuato un recupero precedente rimosso il rif. di tracciamento obsoleto.
  23. Mantenere l'originale pulito e dietro uno; non tirare o spingere con forza.
  24. Successivamente, ispeziona la destinazione prima di pubblicare un ramo.