2012-07-16 16 views
6

Eventuali duplicati:
GIT: Ignoring Version-Controlled FilesCome ignorare i file esistenti, salvati in git?

Ci sono un sacco di risposte intorno .gitignore su StackOverflow, ancora non ho trovato una risposta:

ho un progetto Git esistente, con un readme.md e uno sample_folder/, entrambi al primo livello. Voglio rimuovere questi dal mio repository git (hub) in generale. Ma mi piacerebbe ignorarli, cioè, impedire che vengano tirati, in un determinato repository locale clonato, cioè su una macchina di distribuzione.

.gitignore Capisco, si tratta solo di ignorare file non impegnati? Francamente, non trovo nulla intorno a nascondere (da pull + commit) roba che già è commesso ...

Nei giorni di Perforce avrei semplicemente escluso dalle rispettive 'specifiche client' (che è molto vicino ad un repo clonato in loco):

//whatever/myProject 
-//whatever/myProject/readme.md 
-//whatever/myProject/sample_folder 

Certo, avrei potuto accontentarsi di un secondo ramo in cui ho semplicemente cancellare readme e l'intera cartella del campione. Ma poi, dovrei continuare a unire tutte le piccole correzioni da "sviluppare". Il che è qualcosa, preferirei evitare ... Preferirei piuttosto un'eccezione locale su un ramo (tracciato).

Inoltre, penso che ogni volta che git rm --cached fare commit (che può anche accadere di tanto in tanto dalla mia 'repo distribuzione') ...

+0

è difficile capire il tuo problema ... perché vorresti che i file ignorassero i pull? Posso immaginare la fonte del problema, dal momento che non tutti i repository sarebbero allo stesso stato mentre sono allo stesso commit – CharlesB

+0

Bene, per qualsiasi persona che si occupa di intersting/sviluppatori è utile avere cioè una sample_folder (o una cartella docs o un readme) , in uno scenario di distribuzione tutto questo è superficiale, forse anche problematico ... –

+0

@Wooble: Sembra molto promettente! Grazie mille. Indagherà. –

risposta

0

Questo non è un problema su .gitignore. Se si tratta di codice non, è necessario rintracciarlo in un repository separato tramite i sottomoduli e semplicemente non eseguire alcun comando git submodule sul server. O semplicemente script la rimozione di questi sul computer di distribuzione dopo un checkout.

2

Sembra che potresti utilizzare un checkout git come metodo di implementazione. A volte funziona, a volte serve un po 'di più. Se sono presenti elementi di sviluppo nel repository, è necessario un po 'di più.

Il modo più ovvio per risolvere questo problema è disporre di uno script di distribuzione che esegua il pull e quindi cancelli le directory ei file superflui. Questo purtroppo ti lascia con un repository parziale che potrebbe confondere le persone e aggiunge uno script speciale che deve essere ricordato per essere usato e tenuto aggiornato.

Un altro modo per gestirlo è disporre di un ramo di distribuzione. Crea un ramo, elimina i file e le directory in conflitto, quindi estrai da quel ramo. Sì, dovresti unire le modifiche dal tuo ramo di sviluppo alla distribuzione. Lo vedi come un lavoro ingrato, ma è una salvaguardia. Se si stanno creando rapidamente opportunità di sviluppo e altrettanto rapidamente la distribuzione, si potrebbe avere un problema con il ciclo di distribuzione.

Si desidera un passaggio tra lo sviluppo e la distribuzione in cui è possibile prendere in considerazione e verificare le modifiche. Se non altro, ciò impedisce allo sviluppatore A di spingere un brutto cambiamento e admin B aggrava l'errore inconsapevolmente tirandolo in produzione. Vuoi anche essere in grado di spingere allo sviluppo e condividere il tuo lavoro con altri sviluppatori senza che ALSO rischi di essere spinto in produzione.

Potrebbe essere la singola persona che gestisce lo sviluppo E la distribuzione in questo momento, ma potrebbe non essere più tardi. Se non altro, questo ti protegge dall'includere accidentalmente una modifica instabile allo sviluppo e quindi aggravare quell'errore inserendolo nella distribuzione prima che tu abbia la possibilità di pensare.

+0

Per il rilascio serio avrei certamente un ramo "stabile", naturalmente. Ma per il mio "dispiegamento" veloce e sporco sono molto avverso allo sforzo :) E voglio rimandare le piccole correzioni (senza vedere molte modifiche fasulle, cioè tutte quelle cancellazioni, anche se non le aggiungerò sullo stage). Indagherò il commento di Wooble sopra ... –

5

Forse ho sbagliato la domanda, ma quanto segue non risolverebbe il problema?

git rm --cached readme.md sample_folder/* 
echo "readme.md" >>.gitignore 
echo "sample_folder/*" >>.gitignore 
git commit -am "Untracked some files" 
Problemi correlati