Best practice per IntelliJ IDEA 9 + Maven + Controllo versione

Question

Il progetto utilizza Maven in modo che i file POM siano le principali fonti di informazioni sul progetto. Ci sono alcune impostazioni utili nei file di progetto che sarebbe bello conservare.

OTOH IDEA sembra creare troppe modifiche ridondanti nella struttura del file di progetto che inquina la cronologia SVN e talvolta crea conflitti.

Devo mantenere la directory .idea ei file * .iml sotto controllo 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 di IDEA, * .iml e .idea directory. Contengono informazioni preziose ed è una perdita di tempo per ricrearlo ogni volta che si aggiorna.
2. Creare ramo privato per ogni sviluppatore
3. cd nella directory .idea
4. svn passare al suo ramo controparte privata
5. Non check-in file idea su commit regolari - inquinano storia. Controllali in speciali commit.

In questo modo, si mantiene il contenuto della directory .idea nel controllo della versione ma si tiene fuori dalla modalità di commit regolari. Qualsiasi sviluppatore può avere accesso alle directory IDEA di qualcun altro.

Aggiornamento 2: Dal momento che questa domanda è stato scritto, ho cambiato la mia pratica di non il check-in qualsiasi file IntelliJ nel controllo di versione, come consigliato da molti soccorritori. Questa è la mia pratica corrente sia per Maven che per Gradle. Gli strumenti si sono sviluppati al punto che le informazioni critiche possono sempre essere riprodotte dai file originali .POM o .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 in

Aggiornamento 3:. 7 anni dopo aver chiesto questa domanda sembra essere ancora rilevante. Le stesse migliori pratiche si applicano anche a Gradle (probabilmente anche SBT): non controllare i file IDE, ricrearli se necessario dai file POM, .gradle o SBT di base.

Answer 1

Risposta breve: non mettere questi file nel repository di controllo del codice sorgente in quanto è possibile "generarli" (e questo è ancora più vero se non ne hai 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 hai un pom, puoi creare un progetto nativo abbastanza velocemente.

Per tale motivo, non avrei controllato i file .idea o * .iml sotto il controllo del codice sorgente più di quanto avrei controllato negli stub RMI o nei file di classe.

Answer 3

Vedo che la risposta standard è "non controllare nel file di progetto, solo il .pom". Ma cose come i file .ipr contengono molte impostazioni utili che NON possono essere derivate dal file .pom.Cosa succede se i colleghi utenti di IntelliJ vogliono condividere queste impostazioni? So che i file .ipr sono progettati per essere versionati (vedi this thread per esempio). Vorrei avere una risposta vera, ma non ho ancora trovato una buona pratica in materia.

Answer 4

Penso che dovresti mettere la directory .idea nel controllo di versione. La maggior parte della configurazione contenuta dovrebbe essere monitorata per la versione, ad es. configurazioni del compilatore.

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

IntelliJ Idea mette effettivamente workspace.xml nell'elenco di ignora per impostazione predefinita, quindi se si utilizza Idea per il check-in, si dovrebbe essere tutto impostato senza modificare nulla.

Answer 5

La mia opinione è che dovremmo tenere tutti i file specifici IDE fuori dal controllo versione. L'idea è che dovremmo mantenere quante più informazioni possibili in forma indipendente IDE come i file Maven Pom e così via. Tutte le impostazioni critiche del progetto possono essere mantenute lì. E avendo tutte le principali impostazioni del progetto mantenute nel file pom, non vedo alcun motivo serio per controllare non solo la configurazione del progetto IDEA ma qualsiasi altra configurazione specifica IDE. Inoltre, la configurazione del progetto in stile cartella .idea in realtà inquina i registri di changeset. E vogliamo ancora mantenere le impostazioni del progetto IDEA nel controllo della versione, possiamo almeno memorizzarle in un unico formato di file .ipr.

Answer 6

Sono in ritardo per questa festa, ma questo problema esatto mi ha tormentato. E mi sono ispirato a quello che credo possa funzionare, almeno con il nostro sistema di controllo del codice sorgente.

I file IntelliJ non devono essere archiviati "insieme" con l'autorevole pom.xml e la fonte. La cronologia del controllo della versione non è "inquinata" se quelle modifiche non relative alla sorgente sono registrate in una posizione diversa nell'albero dei sorgenti.

Quindi proverò a spostare i file IntelliJ in una posizione parallela nel sistema di controllo versione, utilizzare un semplice mapping di file/directory per riunire i file di origine e di progetto sul computer dello sviluppatore e monitorare le modifiche nel sistema di controllo della versione che sono puramente ai file che influenzano la compilazione.