Commit di una parte di un file
I blocchi sono casi diversi, non un unico script. Scegli il caso del tuo repository. Sostituisci branch, percorsi e VERIFIED_COMMIT prima dell’uso. I comandi di annullamento valgono solo per la propria operazione attiva; non eseguire entrambe le alternative.
Risposta breve
Git crea il commit dall’indice. Prepara soltanto la correzione e lascia le altre modifiche nella directory di lavoro per commit separati.
Esempio e condizioni
L’esempio contiene una correzione e una stampa di debug nello stesso file. Devono essere due modifiche di testo distinguibili durante la revisione.
Controlla prima di modificare
Confronta git diff e git diff --cached. Il primo mostra le modifiche non preparate; il secondo mostra esattamente il contenuto del prossimo commit.
git status --short
git diff
git diff --cachedConserva un riferimento o checkout separato
Preparare una modifica non cancella quella restante. Indice e directory di lavoro rimangono stati separati che puoi esaminare individualmente.
Primo percorso
In FluxGit apri il diff e usa Stage change sulla correzione. Nel pannello di commit la stampa di debug deve rimanere non preparata.
Scegli consapevolmente l’altro risultato
Nel terminale git add -p consente di accettare o rifiutare gli hunk. Le opzioni s ed e possono dividere un hunk o modificarne la patch quando opportuno.
git add -p -- app.py
git diff --cachedLimiti ed eccezioni
L’unità minima di FluxGit è una modifica dentro un hunk. Una modifica di sei righe viene preparata interamente, non come intervallo arbitrario disegnato col mouse.
Conflitti e pulizia
Rimuovere dallo staging conserva il file; scartare ne modifica il contenuto. FluxGit acquisisce un’istantanea di sicurezza prima dello scarto parziale: sono azioni diverse.
Verifica il risultato
Leggi git diff --cached prima del commit e git show dopo. Controlla anche git diff per verificare che il lavoro pendente sia ancora nel file.
git show --stat HEAD
git diff
git status --shortDomande frequenti
Per un commit ordinario e privato, git reset --soft HEAD^ può riportare il contenuto nell’indice. Verifica lo stato e coordina ogni riscrittura della cronologia condivisa.
Esamina l’operazione in FluxGit
Commit Studio tiene diff e messaggio insieme. Rivedi il contenuto mentre scrivi e crea commit con uno scopo chiaro.
Riferimenti ufficiali Git
Fare commit di una parte di un file in Git
Hai corretto un bug ma lasciato un print di debug nello stesso file? Prepara solo la correzione. Scopri l’area di staging di Git, Stage change in FluxGit e git add -p.
Guarda su YouTube — si apre una nuova scheda
Registrato in un repository di prova.
Leggi la trascrizione della narrazione
- Hai corretto un bug e lasciato un print di debug nello stesso file. Vuoi un commit pulito: la correzione, senza il print.
- Ecco il file in FluxGit: app.py, con due modifiche.
- Ecco perché funziona. Git non fa commit della cartella, ma dell’area di staging. Entrambe le modifiche sono inizialmente solo sul disco. Stage change mette nello staging soltanto la correzione. Il commit include proprio quella; il print resta sul disco, senza commit.
- Apri il file. Il diff mostra entrambe le modifiche, ognuna con il proprio pulsante Stage change.
- Premi Stage change sulla correzione. Solo quella modifica entra nello staging; il print resta dov’è.
- Di nuovo nel pannello di commit: la correzione è nello staging, il print no.
- Scrivi il messaggio ed esegui il commit.
- Il nuovo commit contiene la correzione, e soltanto quella. Il print resta sul disco, senza commit.
- Hai cambiato idea? Annulla ritira il commit. La correzione torna nello staging e i file non cambiano.
- Nel terminale, l’equivalente è git add -p. Git chiede per ogni modifica: sì alla correzione, no al print. Poi fai commit.
- Riepilogo: prepara modifiche, non file interi. Un’idea per commit. E Annulla se sbagli. Prossima lezione: correggere l’ultimo commit.