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ć:
- 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.
- Ż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.
- 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ą.