“Git rm --cached x” vs “git reset head - x”?

163

git rmrimuoverà le voci dall'area di gestione temporanea. Questo è un po 'diverso da git reset HEADquello dei file di "disinstallazione". Con "unstage" intendo che ripristina l'area di stadiazione a ciò che era lì prima di iniziare a modificare le cose. git rmd'altra parte, cancella del tutto il file dallo stage, in modo che non sia incluso nella prossima istantanea del commit, eliminandolo in tal modo efficacemente.

Per impostazione predefinita, a git rm filerimuoverà completamente il file dall'area di gestione temporanea e anche dal disco> (la directory di lavoro). Per lasciare il file nella directory di lavoro, è possibile utilizzare git rm --cached.

Ma qual è esattamente la differenza tra git rm --cached asde git reset head -- asd?

— Pacerier
fonte

Risposte:

219

Esistono tre posizioni in cui un file, per esempio, può essere: l'albero, l'indice e la copia di lavoro. Quando aggiungi un file a una cartella, lo stai aggiungendo alla copia di lavoro.

Quando fai qualcosa di simile git add filelo aggiungi all'indice. E quando lo commetti, lo aggiungi anche all'albero.

Probabilmente ti aiuterà a conoscere i tre flag più comuni in git reset:

git reset [- <mode>] [ <commit>]

Questo modulo reimposta la testa del ramo corrente <commit>e probabilmente aggiorna l'indice (ripristinandolo all'albero di <commit>) e l'albero di lavoro a seconda <mode>, che deve essere uno dei seguenti:
--soft

Non tocca affatto il file indice né l'albero di lavoro (ma reimposta la testa <commit>, proprio come fanno tutte le modalità). Questo lascia tutti i tuoi file modificati "modifiche da impegnare", come direbbe lo stato git.

--misto

Reimposta l'indice ma non l'albero di lavoro (ovvero, i file modificati vengono conservati ma non contrassegnati per il commit) e riporta ciò che non è stato aggiornato. Questa è l'azione predefinita.

--difficile

Reimposta l'indice e l'albero di lavoro. Qualsiasi modifica ai file tracciati nella struttura di lavoro <commit>viene scartata.

Ora, quando fai qualcosa del genere git reset HEAD, ciò che stai effettivamente facendo è git reset HEAD --mixede "ripristinerà" l'indice allo stato in cui si trovava prima di iniziare ad aggiungere file / aggiungere modifiche all'indice (tramite git add) In questo caso, la copia di lavoro e il L'indice (o la stadiazione) erano sincronizzati, ma dopo la reimpostazione sono stati sincronizzati HEAD e l'indice.

git rmd'altra parte rimuove un file dalla directory di lavoro e dall'indice e quando si esegue il commit, il file viene rimosso anche dall'albero. git rm --cachedtuttavia rimuove il file dall'indice da solo e lo mantiene nella copia di lavoro. Questo è esattamente l'opposto di git add file In questo caso, hai reso l'indice diverso da HEAD e funzionante, in quanto HEAD ha la versione del file precedentemente impegnata, la copia funzionante ha avuto l'ultima modifica se presente o il contenuto di HEAD di il file e il file è stato rimosso dall'indice. Un commit ora sincronizzerà l'indice e l'albero e il file verrà rimosso.

— manojlds
fonte

Ho notato che dopo git rm --cachedil git diffcomando non mostra alcun diff, ma git diff --cachedmostra il diff, come se fosse ancora memorizzato nella cache. Il git statustuttavia mostra il file come Untracked. Sembra incoerente.

— Haridsv,

Non importa ... avrei dovuto usare git reset --mixed. Ero un po 'confuso dall'affermazione che git rm --cachedè l'opposto di git add. Preso alla lettera, non è corretto e potrebbe causare danni. Nel mio caso, ho usato git addper aggiungere un file modificato all'area di gestione temporanea e volevo l'opposto di "che aggiunge" non l'aggiunta iniziale del file. + La risposta di Greg Hewgill mi ha aiutato a ottenere un'immagine più chiara.

— Haridsv,

Trovo un po 'confuso l'uso di copia funzionante, albero e albero di lavoro. L'albero di lavoro è la copia di lavoro o l'albero?

— Nealv,

Come menzionato da @haridsv, dire git rm --cached"è l'esatto contrario di git add file" è fuorviante. git reset fileè più vicino a essere l'opposto di git add file.

— Matt Browne,

@Nealv in ritardo, ma per gli altri che trovano questa discussione: copia di lavoro, albero e albero di lavoro si riferiscono tutti alla stessa cosa (nel contesto di git).

— De Novo,

Forse un esempio aiuterà:

git rm --cached asd
git commit -m "the file asd is gone from the repository"

contro

git reset HEAD -- asd
git commit -m "the file asd remains in the repository"

Nota che se non hai cambiato nient'altro , il secondo commit non farà effettivamente nulla.

— Greg Hewgill
fonte

Puoi dirmi cosa significa quel doppio trattino - dopo HEAD in realtà significa?

— yuva,

@yuva: --viene utilizzato per separare le opzioni di comando dai nomi dei file. Se ci fossero sia un ramo che un file chiamato asd, allora git reset HEAD asdsarebbe ambiguo. La --dice "tutto seguendo questo è un nome di file".

— Greg Hewgill,

È git reset HEAD <file>esattamente lo stesso di git rm --cached <file>e poi git add --intent-to-add <file>?

— alcol è cattivo

@alcoholisevil no, tranne in un caso speciale. Vedi questa risposta eccellente e concisa.

— De Novo,

git rm --cached filesarà rimuovere il file dal palco. Cioè, quando commetti il file verrà rimosso. git reset HEAD -- fileripristinerà semplicemente il file nell'area di gestione temporanea allo stato in cui si trovava sul commit HEAD, ovvero annullerà tutte le modifiche apportate a quest'ultimo dall'ultimo commit. Se quella modifica sembra aggiungere di nuovo il file, allora saranno equivalenti.

— yuriks
fonte

Insieme alla nozione (come menzionato in altre risposte) che git rm --cached fileè un po 'l'opposto di git add, questa risposta ha avuto molto senso per me ed è stata piuttosto concisa. Quasi breve come questo commento;)

— rbatt

@rbatt anche solo per mettere il commento qui, e chiarire, git rm --cached filenon è il contrario digit add file . Il comportamento sembra essere l'opposto del git add filecaso specifico in cui è stato aggiunto un nuovo file precedentemente non tracciato. In tutti gli altri casi l'opposto git add fileè git reset HEAD file. git reset HEAD filesi inverte anche git add filenel primo caso (aggiungendo un file non monitorato), e in ogni caso, ecco perché è quello che git suggerisce di fare se si vuole invertire un add git.

— De Novo,