Best practice per IntelliJ IDEA 9 Controllo + Maven + Version

Question

Il progetto sta usando Maven modo che i file POM sono le principali fonti di informazioni di progetto. Ci sono alcune impostazioni utili per i file di progetto che sarebbe bello mantenere.

IDEA OTOH sembra creare troppi cambiamenti ridondanti nella struttura dei file di progetto che inquina la storia SVN e talvolta crea conflitti.

Devo mantenere la directory .idea ei file * .iml sotto controllo di versione? in toto? in parte?

Aggiornamento: Quindi la migliore pratica che ho trovato a lavorare per me e la mia squadra è finora:

1. Check in tutti i file IDEA, * .iml e .idea directory. Essi contengono informazioni preziose ed è uno spreco di tempo per ricreare ogni volta che si aggiorna.
2. Crea ramo privato per ogni sviluppatore
3. cd nella directory .idea
4. svn accenderlo alla sua controparte ramo privato
5. Non check-in file idea su commit regolari - inquinano storia. Controllare loro in su commit speciali.

In questo modo, si mantiene il contenuto della directory in .idea controllo di versione, ma tenerlo fuori del modo di commit regolari. Ogni sviluppatore può avere accesso alle directory IDEA di chiunque altro.

Aggiornamento 2: Dal momento che questa domanda è stato scritto, ho cambiato la mia pratica a non il check-in tutti i file IntelliJ nel controllo di versione, come consigliato da molti soccorritori. Questo è il mio attuale pratica sia per Maven e Gradle. Gli strumenti hanno sviluppato a tal punto che le informazioni critiche può sempre essere riprodotta dal .POM originale o file .gradle. Quando i file cambiano, l'IDE tiene traccia delle modifiche in modo affidabile in modo da non perdere i file IDE che spesso quindi non c'è bisogno di controllare loro.

Aggiornamento 3: 7 anni dopo aver chiesto questa domanda sembra essere ancora attuale. Le stesse migliori pratiche si applicano a Gradle così (probabilmente SBT, troppo):. Non controllare i file IDE in, ricrearli come necessario dal POM base, i file .gradle o SBT

Answer 1

Risposta breve: non mettere questi file nel repository controllo del codice sorgente, come si può "generare" loro (e questo è ancora più vero se non ne hanno bisogno, se sono fastidiosi, se possono rompere gli altri ambiente ).

Io personalmente uso i seguenti valori per svn:ignore:

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings 

Answer 2

Una delle grandi cose di Maven è che esiste il supporto strumento per trasformare un POM in un progetto originario in Eclipse, Idea e Netbeans. Se si dispone di un pom, è possibile creare un progetto nativo abbastanza rapidamente.

Per questo motivo, non voglio il check-in file * .iml .idea o sotto sorgente di controllo più di quanto avrei fatto il check in stub RMI o file di classe.

Answer 3

Credo che si dovrebbe mettere .idea directory in controllo di versione. La maggior parte della configurazione conteneva ci dovrebbe essere la versione monitorati, ad esempio, configs del compilatore.

L'unico file che non appartiene al controllo di versione è .idea / workspace.xml, perché contiene solo la configurazione particolare per l'ambiente locale.

IntelliJ Idea mette effettivamente workspace.xml in ignore list di default, quindi se si utilizza Idea per il check-in, si dovrebbe essere tutti insieme senza cambiare nulla.

Answer 4

Vedo che la risposta standard è "non controllare nel file di progetto, solo il .pom". Ma le cose come i file .ipr contengono un sacco di impostazioni utili che non può essere derivata dal file .pom. Che cosa succede se gli utenti collega IntelliJ vogliono condividere queste impostazioni? So che i file .ipr sono progettati per essere di versione (vedi questa discussione per esempio). Vorrei avere una risposta vera e propria, ma non ho ancora trovato una buona pratica in materia.

Answer 5

La mia opinione è che dovremmo mantenere qualsiasi IDE file specifici di controllo della versione. L'idea è che dovremmo mantenere il più possibile le informazioni in forma indipendente IDE come i file pom Maven e così via. Tutte le impostazioni di progetto critici possono essere tenuti lì. E avendo tutte le principali impostazioni di progetto archiviato nel fascicolo pom non vedo alcuna seria ragione per il check-in di configurazione del progetto IDEA, non solo, ma qualsiasi altra configurazione specifica IDE. Inoltre, .idea configurazione di progetto stile cartella inquina veramente log changeset. E abbiamo ancora voglia di mantenere le impostazioni di progetto IDEA nel controllo di versione, possiamo almeno memorizzarle in formato unico file .ipr.

Answer 6

Sono in ritardo a questo partito, ma questo problema esatto mi ha affligge. E io stavo solo ispirato con quello che credo potrebbe funzionare, almeno con il nostro sistema di controllo del codice sorgente.

I file IntelliJ non devono essere conservati "insieme" con l'autorevole pom.xml e la fonte. La storia controllo di versione non è "inquinato" se le modifiche relative quelli non-source sono registrate in un luogo diverso nella struttura di origine.

Quindi cercherò spostare i file IntelliJ per un posto in parallelo nel sistema di controllo di versione, utilizzare un semplice mappatura di file / cartella di riunificare i file di origine e di progetto sulla macchina di sviluppo, e monitorare i cambiamenti nel sistema di controllo di versione che sono puramente a i file che interessano la costruzione.