Najlepsze praktyki dla IntelliJ IDEA 9 + Maven + Kontrola wersji

Projekt używa Maven więc pliki POM są głównymi źródłami informacji o projekcie. W plikach projektu jest kilka przydatnych ustawień, które warto zachować.

OTOH IDEA wydaje się tworzyć zbyt wiele zbędnych zmian w strukturze plików projektu, które zanieczyszczają historię SVN i czasami powodują konflikty.

Czy powinienem zatrzymać .idea directory i *.pliki iml pod kontrolą wersji? w całości? po części?

Update: więc najlepsza praktyka jaką mam znalazłem pracę dla mnie i mój zespół jest jak na razie:

  1. sprawdź wszystkie pliki IDEA,*.iml i .katalogi pomysłów. Zawierają one cenne informacje i jest to strata czasu, aby odtworzyć je za każdym razem, gdy aktualizujesz.
  2. Utwórz prywatną gałąź dla każdego dewelopera
  3. CD do .katalog idea
  4. svn przełączy go na swój odpowiednik prywatnej gałęzi
  5. nie sprawdzaj plików pomysłów w regularnych commitach-zanieczyszczają one historię. Sprawdź je w specjalnej / align = "left" /

W ten sposób zachowasz treść .katalog idea w kontroli wersji, ale trzymaj go z dala od regularnych commitów. Każdy programista może mieć dostęp do katalogów pomysłów innych osób.

Update 2: ponieważ to pytanie zostało napisane, zmieniłem moją praktykę na , a nie sprawdzanie jakichkolwiek plików IntelliJ w kontroli wersji, jak radzi wielu respondentów. To moja obecna praktyka zarówno dla Mavena, jak i Gradle ' a. Narzędzia rozwinęły się do punktu że krytyczne informacje zawsze można odtworzyć z oryginału .POM lub .pliki gradle. Gdy Pliki się zmieniają, IDE śledzi zmiany niezawodnie, dzięki czemu nie tracisz plików IDE tak często, więc nie ma potrzeby ich sprawdzania.

Aktualizacja 3: 7 lat po zadaniu tego pytania wydaje się być nadal aktualne. Te same dobre praktyki dotyczą również Gradle (prawdopodobnie również SBT): nie sprawdzaj plików IDE, odtwarzaj je w razie potrzeby z podstawowego POM, .gradle lub SBT pliki.

Author: Sasha O, 2009-10-31
Source

6 answers

Krótka odpowiedź: nie umieszczaj tych plików w repozytorium source control, ponieważ możesz je "wygenerować" (A jest to jeszcze bardziej prawdziwe, jeśli ich nie potrzebujesz, jeśli są denerwujące, jeśli mogą zepsuć inne środowisko).

Osobiście używam następujących wartości dla svn:ignore: 

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings
 17
Author: Pascal Thivent,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-01 03:10:10

Jedną z wspaniałych rzeczy w Mavenie jest to, że istnieje wsparcie narzędzia do przekształcania POM w natywny projekt w Eclipse, Idea I Netbeans. Jeśli masz pom, możesz dość szybko utworzyć natywny projekt.

Z tego powodu nie zameldowałbym się .idea lub*.pliki iml pod kontrolą źródła więcej niż bym sprawdzić w RMI stubs lub plików klas.

 15
Author: sal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-01 02:37:14

Myślę, że powinieneś umieścić .katalog idea do kontroli wersji. Większość zawartych tam konfiguracji powinna być śledzona w wersji, np. configs kompilatora.

Jedynym plikiem, który nie należy do kontroli wersji jest .idea / workspace.xml, ponieważ zawiera tylko konfigurację specyficzną dla Twojego środowiska lokalnego.

IntelliJ Idea faktycznie stawia przestrzeń roboczą.domyślnie XML do listy ignorowanych, więc jeśli używasz Idea do check in, powinieneś być ustawiony bez zmiany czegokolwiek.

 14
Author: alexei.vidmich,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-13 18:27:12

Widzę, że standardowa odpowiedź brzmi " nie sprawdzaj w pliku projektu, Tylko .pom". Ale takie rzeczy.pliki ipr zawierają wiele przydatnych ustawień, które nie mogą być wyprowadzone z .plik pom. Co jeśli inni użytkownicy IntelliJ chcą udostępnić te ustawienia? Wiem o tym .pliki ipr są przeznaczone do wersji (Patrz Ten wątek na przykład). Chciałbym mieć rzeczywistą odpowiedź, ale nie znalazłem jeszcze dobrej praktyki w tej sprawie.

 9
Author: mcherm,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-12-07 02:08:19

Moim zdaniem powinniśmy trzymać pliki specyficzne dla IDE poza kontrolą wersji. Chodzi o to, że powinniśmy przechowywać jak najwięcej informacji w formie niezależnej od IDE, takiej jak pliki Maven pom i tak dalej. Wszystkie krytyczne ustawienia projektu mogą być tam przechowywane. I mając wszystkie główne Ustawienia projektu przechowywane w pliku pom nie widzę żadnego poważnego powodu, aby sprawdzić nie tylko konfigurację projektu IDEA, ale każdą inną konfigurację specyficzną dla IDE. Dodatkowo .idea folder style project configuration really zanieczyszcza dzienniki zestawów zmian. I nadal chcemy zachować ustawienia projektu IDEA w kontroli wersji, możemy przynajmniej przechowywać je w jednym .format pliku ipr.

 3
Author: Maksym Govorischev,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-01-18 11:57:52

Jestem spóźniony na tę imprezę, ale ten problem mnie dręczy. Zainspirowało mnie to, co mogłoby zadziałać, przynajmniej z naszym systemem kontroli źródła.

Pliki IntelliJ nie muszą być przechowywane "razem" z autorytatywnym pom.xml i źródło. Historia kontroli wersji nie jest "zanieczyszczona", jeśli te niezwiązane ze źródłami zmiany są rejestrowane w innym miejscu w drzewie źródeł.

Więc spróbuję przenieść pliki IntelliJ w równoległe miejsce w system kontroli wersji, użyj prostego mapowania plików / katalogów, aby połączyć pliki źródłowe i projektowe na maszynie deweloperskiej i monitorować zmiany w systemie kontroli wersji, które są wyłącznie plikami, które wpływają na kompilację.

 1
Author: baliset,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-13 04:50:56