Android studio: l'intera directory .idea dovrebbe essere ignorata in git?


137

Ho visto molti esempi di .gitignorefile per AndroidStudio , alcuni ne contengono , altri .ideano.

C'è una buona ragione per non aggiungere l'intera directory .idea a .gitignore?

Se non deve essere completamente ignorato, ci sono file specifici all'interno di .idea (come .iml) che dovrebbero essere in .gitignore?


Ignoro .ideatranne alcuni dei file sotto .idea/runConfigurations/.
Daniel,

Risposte:


104

Puoi dare un'occhiata a questa pagina:

Documento IntelliJ sui file di configurazione del progetto

Nel "Formato basato su directory", una riga particolare è interessante:

La directory .idea contiene un set di file di configurazione (.xml). Ogni file contiene solo una parte dei dati di configurazione relativi ad una certa area funzionale che si riflette nel nome di un file, ad esempio, compiler.xml, encodings.xml,modules.xml .

Quasi tutti i file contengono informazioni chiave per il progetto stesso, come nomi e posizioni dei suoi moduli componenti, impostazioni del compilatore, ecc. Pertanto, questi file possono (e dovrebbero) essere tenuti sotto controllo della versione.

Tuttavia, odio correttamente rendere dipendente dal progetto IDE (attualmente sto lavorando a un progetto realizzato con NetBeans e mi fa male usarlo con Eclipse che diventa lo standard della mia azienda).

Quindi, per rispondere alla tua domanda:

  1. Se non usi qualcosa come Maven o Gradle per gestire le dipendenze e costruire: mantieni la directory sotto il controllo della versione . In questo modo, la configurazione corretta del progetto e delle dipendenze sarà disponibile per tutti. Nella controparte, tutti gli sviluppatori dovranno impostare il proprio ambiente esattamente nello stesso modo in cui lo si definisce nei file di configurazione.
  2. Se usi qualcosa come Maven o Gradle: configura correttamente questi strumenti e non tenere la directory sotto il controllo della versione . In realtà, tutte le informazioni contenute nei file di configurazione devono essere archiviate nei file Maven / Gradle. Quindi lascia che i tuoi sviluppatori configurino il loro IDE a seconda del loro ambiente. In questo modo, usando Eclipse, IntelliJ, Linux, Windows ... non sarà più un problema.

9
Nota il prossimo paragrafo, però: "L'eccezione è il file workspace.xml. Memorizza le tue impostazioni personali ... Quindi è improbabile che tu voglia condividere questo file con i tuoi colleghi."
Dalbergia,

40

OK, quindi dopo alcune risposte "Sì" e "No", sto aggiungendo una risposta "Sì e no" :)

Il problema è che .ideaviene utilizzato sia per la configurazione della build del progetto (dichiarazione delle dipendenze) sia per le impostazioni del progetto (ispezioni, ecc.).

Sicuramente non vuoi usare il tuo IDE per la tua configurazione di build, ma potresti voler condividere le impostazioni tra il team. Ecco perché è necessario ignorare solo una parte del .ideacontenuto (come la librariescartella e il modules.xmlfile), ma tenere gli altri nel controllo di versione (ad esempio, la copyright, dictionariese inspectionProfilesle cartelle ei file sotto .ideacome dynamic.xml, codeStyleSettings.xmle così via).


In che modo verrebbero indirizzati i file iml?
Dors

1
i file iml dovrebbero assolutamente essere ignorati.
JBaruch,

1
Sto ancora pensando che le configurazioni non debbano essere conservate in file dipendenti dall'IDE e quindi Maven / Gradle sono molto meglio per farlo.
mithrop,

@mithrop il fatto è che non puoi dichiarare questo tipo di configurazione nel file Maven / Gradle. È il formato proprietario di Idea e non ha alternative portatili in Maven / Gradle.
JBaruch,

Oh sì, hai ragione. Comunque, se non riesci a metterlo in file Maven / Gradle, avrai un problema con la prossima volta che importi il ​​progetto in un altro IDE (che è il problema che odio gestire). Ma sono totalmente d'accordo con te (se leggi la mia risposta, vedrai che lo sono davvero): includi i file o non dipende dalle tue esigenze :)
mithrop

7

Il concetto di mantenere la configurazione del progetto in VC è valido. L'ho fatto con il mio team perché a tutti i nostri sviluppatori è capitato di usare PHPStorm per i nostri progetti e quindi aveva senso mantenere una configurazione comune ... nel concetto. Volevamo usare gli stessi file di dizionario, le stesse regole standard di codifica e le stesse configurazioni di plugin.

Il motivo per cui lo qualifico con "in concept" è perché c'erano problemi con la cartella .idea di JetBrains che ci hanno portato a non essere in grado di usarlo. Questi erano probabilmente problemi che avrebbero potuto essere evitati o risolti, ma non ci era chiaro come farlo nel modo giusto, e pensiamo che sia colpa di JetBrains perché come sviluppatori non abbiamo tempo né desideriamo cercare soluzioni su come realizzare il nostro IDE funziona correttamente.

Detto questo, i problemi riscontrati sono i seguenti:

  • Il collegamento simbolico delle cartelle di progetto non funziona correttamente. Quando installo i miei progetti, li collego alla mia home directory. Ciò che abbiamo scoperto è che il progetto è stato impostato per utilizzare il collegamento simbolico esatto anziché trattarlo come una directory concreta. Ciò significa che se un altro sviluppatore mantiene il suo progetto in un posto diverso, o semplicemente non utilizza collegamenti simbolici, l'intera directory mancherà dal navigatore del progetto perché sta letteralmente cercando il collegamento simbolico. Quel che è peggio è che non sono mai riuscito a trovare questo valore di percorso nella configurazione. Non siamo riusciti a trovare la configurazione esatta nei file che costituiscono la nostra cartella .idea.
  • I file di definizione sono partizionati agli utenti per impostazione predefinita. Questo significa che se voglio aggiungere una parola al mio dizionario, questa verrà elencata come una definizione per me, jgreathouse, ma altri utenti avranno una propria sezione di definizione. Le parole contrassegnate verranno comunque visualizzate come un errore di ortografia per gli altri utenti. Questo non è desiderabile. Il motivo per cui lo aggiungo al mio file di definizione è perché l'IDE è sbagliato. Voglio che queste definizioni siano condivise in modo intuitivo con altri utenti.
  • I colleghi hanno continuato a sovrascrivere le configurazioni perché il loro IDE avrebbe sovrascritto le configurazioni con la loro configurazione attualmente in memoria. Quello che voglio dire è che uno sviluppatore funzionerebbe e unirebbe il loro repository dall'origine, che conterrebbe una modifica della configurazione del progetto, invece che le loro configurazioni IDE che cambiano, o anche dando loro una scelta, sovrascriverebbe automaticamente la configurazione .idea con l'attuale configurazione in memoria del loro IDE. A mio avviso, ciò rende la configurazione .idea inutilizzabile come configurazione condivisa. Per ovviare a questo, lo sviluppatore dovrebbe letteralmente chiudere quell'istanza del proprio IDE, estrarre il repository e riaprire il proprio IDE. Non ha senso mantenere una configurazione condivisa se l'IDE la sovrascrive istantaneamente con la configurazione attualmente in memoria. E'

Ho già fatto questi tipi di configurazioni IDE condivise in VC con Visual Studio e Netbeans ed è sempre andato tutto bene; ma con .idea sembra semplicemente inutilizzabile, il che è deludente. Vorrei che JetBrains potesse sfruttarlo e renderlo un'esperienza utente migliore.


> invece che il loro IDE cambi le configurazioni, o anche dando loro una scelta, sovrascriverebbe automaticamente la configurazione .idea con l'attuale configurazione in memoria del loro IDE. Wow, è davvero sfortunato. Buono a sapersi!
Greg Price,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.