Git add -p: linee specifiche per la fase e commit mirati

Per confermare solo una parte di un file, metti in scena le modifiche che desideri con `git add -p -- path/to/file`, rivedile con `git diff --cached`, quindi conferma. Le modifiche rimanenti rimangono nei tuoi file di lavoro. In GitTree, apri il file diff, seleziona le righe modificate e scegli Stage Lines per preparare lo stesso tipo di commit mirato.

Supponiamo che tu abbia corretto un bug di convalida del checkout, quindi abbia iniziato a riorganizzare lo stesso componente. Un revisore dovrebbe essere in grado di comprendere la correzione del bug senza leggere un refactoring incompleto. Questa guida separa questi cambiamenti prima che diventino storia. L'esempio animato utilizza GitTree, il client che creiamo per macOS, Windows e Linux. L'allestimento parziale appartiene al piano gratuito; le build ufficiali attuali richiedono l'accesso.

Albero di lavoro, area di staging e commit: cosa viene salvato?

La messa in scena è una fase di selezione, non un commit e non un push. Un file può essere parzialmente messo in scena: l'indice contiene una versione mentre l'editor mostra tutte le modifiche. Se modifichi di nuovo dopo la gestione temporanea, la versione gestita non si aggiorna automaticamente. Rivedilo di nuovo prima di impegnarti. Il grafico visivo del commit aiuta a controllare la cronologia una volta esistente il commit.

Come usare git add -p su un file

Inizia con git status e controlla tutto ciò che è già stato messo in scena. La modalità Patch aggiunge le modifiche selezionate all'indice esistente; non rimuove le selezioni precedenti. In questo esempio, sostituisci src/checkout.ts con il tuo file di testo tracciato, quindi accetta solo la correzione di convalida quando Git chiede informazioni su ciascun blocco.

git status
git diff --cached
git diff -- src/checkout.ts
git add -p -- src/checkout.ts
git diff --cached
git diff -- src/checkout.ts
git commit -m "fix: validate checkout input"

Esegui il commit finale solo dopo aver esaminato le differenze in fasi e testato la modifica prevista. git diff --cached mostra cosa registrerà il commit; plain git diff mostra ciò che rimarrà non impegnato. Non utilizzare git commit -a o fornire percorsi di file a git commit per questo flusso di lavoro: questi moduli possono ignorare la selezione parziale che hai appena preparato.

Dividere un pezzo quando la correzione e il refactoring sono vicini

Un pezzo è un blocco di righe vicine modificate con il contesto. La modalità patch può raggruppare insieme la correzione e il refactoring. Usa s per chiedere a Git di dividere il blocco. Se le modifiche non possono essere separate automaticamente, e apre un editor di patch oppure un selettore di riga visivo può aiutarti a scegliere le aggiunte e le rimozioni desiderate.

Per una sostituzione, considera sia la linea rimossa che la sua sostituzione come un cambiamento logico. Selezionandone solo la metà puoi produrre codice che non hai mai visto nel tuo editor. La modifica avanzata delle patch è facoltativa; se non riesci a spiegare il risultato messo in scena, rimuovilo e scegli un confine più chiaro. Gli impegni mirati devono funzionare da soli, non essere semplicemente piccoli.

Scarica GitTree per esaminare una differenza mista e creare visivamente commit mirati. Puoi usarlo su un repository esistente insieme al terminale; entrambi leggono la stessa area di staging di Git.

Disattiva le modifiche senza eliminare le modifiche

git restore --staged -- src/checkout.ts
# Or choose which staged blocks to remove:
git restore --staged -p -- src/checkout.ts

Questi sono comandi alternativi. Con --staged, il ripristino modifica l'indice anziché il file di lavoro. Per un repository con commit, normalmente reimposta il contenuto messo in scena verso HEAD. Senza --staged, il ripristino può sovrascrivere le modifiche funzionanti, quindi mantieni chiara la distinzione. In GitTree scegli Unstage, non Scarta, quando vuoi modificare solo ciò che include il commit successivo.

Perché un file appare due volte o non è possibile organizzare una riga

Un file sia in File gestiti che in File non gestiti in genere indica una gestione temporanea parziale o una modifica successiva, non un file duplicato. Un nuovo file di testo non tracciato potrebbe richiedere git add -N -- path/to/new-file prima che la modalità patch possa offrire i suoi contenuti. I file binari non hanno porzioni di testo ordinarie; GitTree mette in scena anche le ridenominazioni, i puntatori LFS e le modifiche ai sottomoduli come operazioni sull'intero file. Se lo spazio bianco è nascosto, mostralo prima di selezionare le modifiche relative ai soli spazi bianchi.

Se un editor o un formattatore modifica il file dopo aver aperto il suo diff, GitTree potrebbe rifiutare una selezione di righe non aggiornate. Aggiorna il differenziale e scegli di nuovo. Evitare di suddividere le modifiche strettamente accoppiate solo per raggiungere un numero di righe inferiore. Per un'interruzione dell'attività, metti da parte il lavoro non finito; per la cronologia mista già impegnata, consulta la guida interattiva al rebase.

Testa il commit che stai preparando, non solo i file dell'editor

Il normale comando di test viene eseguito su file di lavoro, che includono ancora modifiche non graduali. Il superamento dei test non dimostra che il commit parziale sia completo. Per una suddivisione importante, esegui il primo commit locale, quindi ispeziona e testa lo snapshot impegnato in un checkout o in un albero di lavoro pulito separato. Aggiungi la dipendenza mancante se fallisce prima di condividere il ramo. La guida all'albero di lavoro spiega come cartelle separate aiutano a tenere separate queste versioni.