Jak radzić sobie z plikami projektów IntelliJ IDEA pod kontrolą źródła Git, które ciągle się zmieniają?

151

Wszyscy w naszym zespole używają IntelliJ IDEA i uważamy, że przydatne jest umieszczanie plików projektu (.ipr i .iml) w kontroli źródła, abyśmy mogli udostępniać konfiguracje kompilacji, ustawienia i inspekcje. Ponadto możemy następnie użyć tych ustawień inspekcji na naszym serwerze ciągłej integracji z TeamCity. (Plik .iws obszaru roboczego dla każdego użytkownika znajduje się w pliku .gitignore, a nie w kontroli źródła).

Jednak te pliki zmieniają się w niewielkim stopniu, gdy robisz cokolwiek w IDEA. W bazie danych IDEA ( IDEA-64312 ) występuje problem , więc być może można by uznać to za błąd w IDEA, ale będziemy musieli z nim żyć w dającej się przewidzieć przyszłości.

Do niedawna używaliśmy Subversion, ale ostatnio przerzuciliśmy się na Git. Każdy z nas właśnie przyzwyczaił się do posiadania listy zmian plików projektów, które zignorowaliśmy i nie wpisywaliśmy, chyba że były zmiany w plikach projektu, którymi chcieliśmy się podzielić z innymi. Ale w przypadku Gita, prawdziwą mocą wydaje się (z tego, co badamy) ciągłe rozgałęzianie, które zachęca, a przełączanie się między gałęziami jest uciążliwe, ponieważ pliki projektu zawsze były modyfikowane. Często może po prostu jakoś scalić zmiany i próbuje poradzić sobie ze zmianami pliku projektu, które są teraz stosowane w nowej gałęzi. Jeśli jednak nowa gałąź zmieniła pliki projektu (na przykład gałąź pracuje nad nowym modułem, którego jeszcze nie ma w innych gałęziach), git po prostu zgłasza błąd, którego nie robi ' Nie ma sensu scalanie plików, gdy zarówno gałąź ma zmiany, jak i zmiany lokalnie, i raczej rozumiem jego punkt widzenia. Z wiersza poleceń można użyć "-f" w poleceniu "git checkout", aby wymusić na nim wyrzucenie lokalnych zmian i użycie zamiast tego gałęzi, ale (1) polecenie Git Checkout GUI w IDEA (10.5.1) wydaje się, że nie ma takiej opcji, którą możemy znaleźć, więc musielibyśmy regularnie przełączać się na wiersz poleceń i (2) Nie jesteśmy pewni, czy chcemy mieć w zwyczaju używanie tego flaga i nakazanie Gitowi odrzucenia naszych lokalnych zmian.

Oto kilka przemyśleń na temat opcji, z którymi musimy sobie poradzić:

  1. Całkowicie usuń pliki projektu spod kontroli źródła. Umieść je w .gitignore i roześlij do każdej osoby i TeamCity w inny sposób, na przykład umieszczając je w innym miejscu kontroli źródła lub pod innymi nazwami. Nasz zespół jest na tyle mały, że ta opcja jest wystarczająco możliwa do rozważenia, ale nie wydaje się świetna.
  2. Żyj dalej, starając się mieć pewność, że zarządzasz plikami, które mamy w poszczególnych gałęziach w danym momencie. W ramach tego możemy zachęcić każdego dewelopera do posiadania więcej niż jednej kopii każdego projektu w swoim systemie, aby każdy mógł wyewidencjonować go do innej gałęzi z możliwie różnymi zestawami plików projektu.
  3. Spróbuj umieścić tylko projekt (.ipr) w kontroli źródła, a pliki modułu (.iml) nie znajdują się w kontroli źródła ani w pliku .gitignore. Najważniejszą rzeczą, która wydaje się regularnie zmieniać samodzielnie w .ipr, jest kolejność współdzielonych konfiguracji kompilacji, ale może możemy po prostu udostępnić oddzielnie informacje o tym, jak je skonfigurować. Nie jestem do końca pewien, jak IDEA radzi sobie z tego rodzaju rzeczami, mając tylko niektóre swoje pliki, zwłaszcza przy nowej kasie.

Myślę, że mam nadzieję, że jest jakieś oczywiste (lub nieoczywiste) rozwiązanie, którego przegapiliśmy, być może zajmując się ogromną możliwością dostosowywania, którą wydają się mieć Git i IDEA. Ale wygląda na to, że nie możemy być jedyną drużyną mającą ten problem. Pytania, które są trochę podobne w przypadku przepełnienia stosu, to 3495191 , 1000512 i 3873872 , ale nie wiem, ponieważ są one dokładnie tym samym problemem i może ktoś może wymyślić zalety i wady dla różnych podejść, które opisane, podejścia wymienione w odpowiedziach na te pytania lub podejścia, które zalecają.

git version-control intellij-idea Ostry ból
źródło
2
zobacz stackoverflow.com/questions/3041154/… -> IDEA FAQ: devnet.jetbrains.com/docs/DOC-1186
Matthew Cornell
Odpowiedź poniżej podała gitignore.io jako dobrą podstawę. Znalazłem to przydatne, nawet jeśli trzy lata po fakcie: gitignore.io/api/java,android,eclipse,intellij
WernerCD
Zwróć uwagę, że problem z IDEA youtrack.jetbrains.com/issue/IDEA-64312 , o którym wspomniałem, jest oznaczony jako naprawiony w IntelliJ IDEA 14, więc ci, którzy używają najnowszej wersji i chcą zachować pliki pod kontrolą źródła, mogą teraz mieć z tym lepszy czas niż wtedy, gdy opublikowałem to pytanie.

Odpowiedzi:

48

Możesz użyć struktury projektu opartej na katalogach IDEA , gdzie ustawienia są przechowywane w katalogu .idea zamiast w pliku .ipr. Daje bardziej szczegółową kontrolę nad tym, co jest przechowywane w kontroli wersji. Pliki .iml będą nadal dostępne, więc nie rozwiązuje to przypadkowych zmian w nich (może utrzyma je poza kontrolą źródła?), Ale udostępnianie rzeczy, takich jak styl kodu i profile inspekcji, jest łatwe, ponieważ każdy z nich będzie we własnym pliku w katalogu .idea.

Esko Luontola
źródło
Przejście do struktury opartej na katalogach zdecydowanie pomogło. Usunęliśmy pliki .iml spod kontroli źródła, co sprawia, że ​​IDEA jest trochę zdezorientowana przy pierwszym sprawdzaniu, ale na razie wydaje się to najlepszym kompromisem. Musieliśmy również uruchomić inspekcje TeamCity z pliku Maven i wyeksportowanego profilu inspekcji, ale to też zadziałało. Dziękuję Ci!
Link jest uszkodzony. Nie jestem pewien, jaka była oryginalna treść, ale tutaj jest link do odpowiedniego dokumentu na temat struktury projektu IDEA. A oto kolejny link dotyczący tego konkretnego problemu.
Ben. 12
31

Z oficjalnego DOC: http://devnet.jetbrains.com/docs/DOC-1186

W zależności od formatu projektu IntelliJ IDEA (na podstawie pliku .ipr lub katalogu .idea), należy umieścić następujące pliki projektu IntelliJ IDEA pod kontrolą wersji:

Format oparty na pliku .ipr

Udostępnij plik projektu .ipr i wszystkie pliki modułów .iml, nie udostępniaj pliku .iws, ponieważ przechowuje ustawienia specyficzne dla użytkownika.

.idea format oparty na katalogu

Udostępnij wszystkie pliki w katalogu .idea w katalogu głównym projektu, z wyjątkiem plików workspace.xml i tasks.xml, które przechowują ustawienia użytkownika, a także współużytkuj wszystkie pliki modułów .iml.

Umieściłem to w moim .gitignore:

#Project
workspace.xml
tasks.xml
Felipe
źródło
8
Tak, i jak powiedziałem w pytaniu, udostępniliśmy pliki .ipr i .iml, a nie .iws. Problem polega na tym, że w youtrack.jetbrains.com/issue/IDEA-64312 pliki .iml zmieniają się cały czas, co prowadzi do częstych konfliktów. Utrzymywanie plików .iml poza kontrolą źródła wydaje się działać lepiej dla nas, ponieważ IDEA regeneruje je z Maven POM, a następnie mogą po prostu zmieniać lokalnie bez konfliktów z innymi programistami. Dzięki!
Przy takim podejściu mamy problem z niektórymi nazwami zasobów, na przykład: wersje Android JDK. Niektórzy członkowie naszego zespołu mają różne nazwy lub różne wersje skonfigurowanego zestawu SDK. Wysyłając pliki projektu do repozytorium, musisz dopasować tego rodzaju sprawy do swojego zespołu. Do wczoraj nie byliśmy przyzwyczajeni do wysyłania plików proj do repozytorium, ale stało się to trudne, ponieważ nasz projekt stał się duży i trudny do skonfigurowania.
Felipe
Ujednolicenie używanych zestawów SDK i ścieżek względnych jest prostym i skutecznym rozwiązaniem
Kumait
1
Tak. Teraz wszystkie nasze moduły wskazują na „Project SDK” i wspólnie z zespołem korzystamy z tego samego zestawu SDK. Przynajmniej jest tylko jedno miejsce do modyfikacji. Ale IntelliJ mógłby to zrobić lepiej.
Felipe
23

Dostępna jest oficjalna odpowiedź . Zakładając, że używasz nowoczesnego (i teraz domyślnego) .ideaformatu projektu folderu:

  • Dodaj wszystko ...
  • Z wyjątkiem .idea/workspace.xml(który jest specyficzny dla użytkownika)
  • Z wyjątkiem .idea/tasks.xml(który jest specyficzny dla użytkownika)
  • Z wyjątkiem niektórych innych plików, które mogą zawierać hasła / klucze / itp. (Szczegółowe informacje znajdują się powyżej)

Ten przykładowy plik .gitignore może być przydatnym źródłem informacji, ale nadal powinieneś przeczytać powyższy link, aby zrozumieć, dlaczego te wpisy się pojawiają i zdecydować, czy ich potrzebujesz.

Osobiście również ignoruję ten .idea/find.xmlplik, ponieważ wydaje się on zmieniać za każdym razem, gdy wykonujesz operację wyszukiwania.

Drew Noakes
źródło
1
Bazując na linku „sample gitignore file”, poszedłbym o krok dalej i cieszę się, że to dostarczyłeś. przejdź do adresu bazowego i możesz łączyć różne typy, aby uzyskać „pełny” gitignore. Dla mojego projektu na Androida, który używa oczywiście Java, Android, Eclipse, IntelliJ: gitignore.io/api/java,android,eclipse,intellij
WernerCD
16

Usunąłem plik workspace.xml z kontroli źródła (+ dodano do .gitignore).

zrywak234
źródło
10

Nasz zespół nie sprawdza plików IntelliJ specyficznych dla ścieżki. Wychodzimy z założenia, że ​​ludzie wiedzą, jak używać IDE i założyć projekt. Pliki IntelliJ trafiają na listę „ignorowanych” zmian.

AKTUALIZACJA:

Odpowiedź jest teraz łatwiejsza, gdy używam Mavena i jego domyślnej struktury katalogów.

IntelliJ powinien zostać poproszony, aby ignorować wszystkie pliki /.svn, /.ideai /targetfoldery. Przechowywane jest wszystko, co dotyczy informacji o ścieżce danej osoby /.idea.

Wszystko inne jest uczciwą grą, jeśli chodzi o zaangażowanie w Subversion lub Git.

duffymo
źródło
14
Konfigurowanie projektu nie jest trudne, ponieważ nie zdarza się to często, ale bardzo przydatne jest udostępnianie konfiguracji kompilacji i profili inspekcji bez konieczności wysyłania zrzutów ekranu pocztą e-mail.
1
Sprawdź rzeczy, które nie są zależne od ścieżki osoby.
duffymo
2

Aby podzielić się innym podejściem zastosowanym przez mój zespół: po prostu przenieś wszystkie pliki związane z IDE do innej lokalizacji, w której IntelliJ nie rozpoznaje, i utwórz skrypt kopiujący je do żądanej „aktywnej” lokalizacji, która jest ignorowana przez GIT.

Zaletą tego podejścia jest to, że zachowano możliwość udostępniania ustawień IDE poprzez kontrolę wersji. Jedyną wadą jest to, że musisz zdecydować, kiedy uruchomić skrypt (prawdopodobnie raz na klon obszaru roboczego lub gdy wymagane są zmiany) i możesz to zautomatyzować, włączając skrypt do procesu kompilacji lub przechwytywania po scaleniu.

To podejście opiera się na tym, że IntelliJ przeszukuje tylko określone lokalizacje pod kątem swoich plików ustawień, więc stosuje się je również do plików konfiguracyjnych struktury. Właściwie zignorowaliśmy plik Grails .properties w ten sam sposób, więc programiści nie będą przypadkowo rejestrować swoich lokalnych zmian w konfiguracji.

Shawn
źródło