Se non hai idea di cosa sia GIT, se non l’hai mai usato, allora quello che segue potrà sembrarti una accozzaglia di frasi italiane prive di senso. Se ignori queste basi, allora ingora anche il resto dell’articolo.

Ne va della mia e tua salute mentale.
[st_divider_shadow]

git è un gestore di revisioni di codice, non ho idea se esiste un modo più semplice per descriverlo.

Ha una memoria di ferro, ricorda tutto quello che gli si dice di ricordare, anche per sbaglio. Basta scorrere lo storico dei vari commit, per vedere l’evoluzione del codice registrato nel repository, vedere l’elenco di tutti i files memorizzati nello storico.

A volte capita di trovare in un progetto dei files che sono stati importati nello storico, e subito dopo, o pochi commit dopo, sono stati messi in .gitignore (sono stati iscritti nel dimenticatoio di git).
Succede con file di cache, directory con files elaborati a runtime, files di progetto o workspace del proprio ambiente di lavoro.

Banalmente è successo che sono stati aggiunti in un commit e non ce ne siamo resi conto.

Finché il progetto su cui lavoriamo è su una sola postazione, questo inconveniente non ci non crea particolari problemi.
Ma quando si lavora su progetti condivisi con altri sviluppatori, questi file prima o poi subiscono qualche modifica o in locale o in remoto, per via che qualcuno ci scrive dentro, vengono distribuiti nuovi aggiornamenti di questi files nei commit. E quando vai a sincronizzarti con il repository centrale iniziano gli incubi.
Le operazioni più banali iniziano a segnalare conflitti, proponendoti di risolverli con noiose sessioni di merge, non credo che abbia senso mettersi a fondere il file di log del server, o qualche altro files ameno. 
Aggiungere i files incriminati al .gitignore non serve, perché git riconosce i files che ha nello storico e cerca di tenere traccia di eventuali modifiche. Alla prima modifica o al primo pull dal server, ricompaiono da committare o con qualche conflitto da gestire nel merge, rallentando il nostro lavoro. Il .gitignore funziona solo con files che non sono ancora stati tracciati nello storico.

Il trucco: L’amnesia

La strategia che segue è applicabile a quei files che possono essere cancellati, che quindi non servono che vengano ulteriormente condivisi. Perché ad esempio vengono ricreati runtime dall’applicativo: configurazione ambiente di lavoro, log, risultati di elaborazioni runtime ecc.

Per toglierseli dai piedi definitivamente occorre che git li dimentichi…

La prima cosa consiste nel cancellare dal sistema i files, di cui vogliamo perdere le tracce. Poi proseguiamo istruendo git di perdere le tracce:
[code]
git rm -r –cached .
git add .
git commit -am "Git dimentica questi files inutili"
[/code]

Questo però potrebbe comportare la cancellazione di molteplici files dalla storia del repository. Questo succede perchè nel frattempo sono finiti nel .gitignore, ma essendo files che non vengono mai toccati non ci hanno causato alcun fastidio finora, non ci eravamo nemmeno accorti della loro presenza.

È consigliabile allora procedere sui singoli file che vogliamo “dimenticare”. Prima li rimuoviamo dallo storico, ancora prima di cancellarli, altrimenti non li trova nel path e git si ferma con un errore. Poi effettuiamo il commit della modifica, e solo in fine andiamo a rimuovere il file fisicamente. Ecco un esempio:

[code]
git rm –cached pathdelfile
git commit -am "Git dimentica questo file inutile"
rm pathdelfile
[/code]