Tutti nel nostro team utilizzano IntelliJ IDEA e riteniamo utile mettere i propri file di progetto (.ipr e .iml) nel controllo del codice sorgente in modo da poter condividere configurazioni, impostazioni e ispezioni. Inoltre, possiamo utilizzare tali impostazioni di ispezione sul nostro server di integrazione continua con TeamCity. (Abbiamo il file .iws dell'area di lavoro per utente nel file .gitignore e non nel controllo del codice sorgente.)
Tuttavia, quei file cambiano in modo modesto quando fai qualsiasi cosa in IDEA. C'è un problema nel database dei problemi di IDEA ( IDEA-64312 ), quindi forse uno potrebbe considerarlo un bug in IDEA, ma è uno che dovremo convivere per il prossimo futuro.
Fino a poco tempo fa utilizzavamo Subversion, ma recentemente siamo passati a Git. Ci eravamo appena abituati ad avere un elenco di modifiche dei file di progetto che abbiamo ignorato e non abbiamo effettuato il check-in a meno che non ci fossero modifiche ai file di progetto che volevamo condividere con altri. Ma con Git, il vero potere sembra essere (da quello che stiamo esplorando) il continuo dirottamento che incoraggia, e il passaggio tra i rami è un problema con i file di progetto che sono sempre stati modificati. Spesso può semplicemente unire le modifiche in qualche modo e cerca di gestire le modifiche ai file di progetto che ora vengono applicate al nuovo ramo. Tuttavia, se il nuovo ramo ha cambiato i file di progetto (come il ramo sta funzionando su un nuovo modulo che non si trova ancora negli altri rami), git genera un errore che non Non ha alcun senso unire i file quando entrambi i rami hanno delle modifiche e tu hai delle modifiche localmente, e posso piuttosto comprenderne il punto. Dalla riga di comando, è possibile utilizzare "-f" sul comando "git checkout" per forzarlo a eliminare le modifiche locali e utilizzare invece le diramazioni, ma (1) il comando Git Checkout GUI in IDEA (10.5.1) non sembra averlo come un'opzione che possiamo trovare, quindi dovremmo passare alla riga di comando su base regolare e (2) non siamo sicuri di voler prendere l'abitudine di usarlo bandiera e dicendo a Git di eliminare i nostri cambiamenti locali.
Quindi, ecco alcuni pensieri che abbiamo sulle opzioni che dobbiamo affrontare:
- Elimina completamente i file di progetto dal controllo del codice sorgente. Inseriscili in .gitignore e distribuiscili a ogni persona e TeamCity in altri modi, magari inserendoli nel controllo del codice sorgente da qualche altra parte o con altri nomi. Il nostro team è abbastanza piccolo questa opzione è abbastanza fattibile da considerare, ma non sembra eccezionale.
- Continua a conviverci, cercando di essere sicuro di gestire quali file abbiamo su quali rami in un determinato momento. Come parte di questo, potremmo incoraggiare ogni sviluppatore ad avere più di una copia di ciascun progetto sul proprio sistema, in modo che possano aver fatto il check-out in un ramo diverso con possibilmente diversi set di file di progetto.
- Prova ad avere solo il progetto (.ipr) nel controllo del codice sorgente, con i file del modulo (.iml) non nel controllo del codice sorgente e nel file .gitignore. La cosa principale che sembra cambiare da sola nel .ipr su base regolare è l'ordine delle configurazioni di build condivise, ma forse possiamo semplicemente condividere le informazioni separatamente su come impostarle. Non sono del tutto sicuro di come IDEA affronti questo genere di cose solo con alcuni dei suoi file, specialmente in un nuovo checkout.
Immagino di sperare che ci sia qualche soluzione ovvia (o non ovvia) che ci siamo persi, forse affrontando l'enorme personalizzazione che entrambi sembrano avere Git e IDEA. Ma sembra che non potremmo essere l'unica squadra che ha questo problema. Le domande che sono simili in Stack Overflow includono 3495191 , 1000512 e 3873872 , ma non so perché sono esattamente lo stesso problema e forse qualcuno può inventare i pro e i contro per i vari approcci che ho delineato, approcci elencati nelle risposte a tali domande o approcci che raccomandano.