Android Studio - czy cały katalog .idea powinien znajdować się w git?

Widziałem wiele przykładów .gitignoreplików dla AndroidStudio , niektóre .ideaw nich mają , a niektóre nie.

Czy jest dobry powód, aby nie dodawać całego katalogu .idea do .gitignore?

Jeśli nie należy go całkowicie zignorować, czy wewnątrz .idea są określone pliki (takie jak .iml), które powinny znajdować się w .gitignore?

Możesz spojrzeć na tę stronę:

Dokument IntelliJ dotyczący plików konfiguracyjnych projektu

W „formacie opartym na katalogach” interesujący jest konkretny wiersz:

Katalog .idea zawiera zestaw plików konfiguracyjnych (.xml). Każdy plik zawiera tylko część danych konfiguracyjnych dotyczących określonego obszaru funkcjonalnego co znajduje odzwierciedlenie w nazwie pliku, na przykład compiler.xml, encodings.xml, modules.xml.

Prawie wszystkie pliki zawierają podstawowe informacje dotyczące samego projektu, takie jak nazwy i lokalizacje jego modułów składowych, ustawienia kompilatora itp. Dlatego te pliki mogą (i powinny) być utrzymywane pod kontrolą wersji.

Jednak NIENAWIDZĘ uzależniać projektu od IDE (obecnie pracuję nad projektem wykonanym w NetBeans i boli mnie używanie go z Eclipse, które staje się standardem w mojej firmie).

A więc odpowiadając na twoje pytanie:

1. Jeśli nie używasz czegoś takiego jak Maven lub Gradle do zarządzania zależnościami i budowania: utrzymuj katalog pod kontrolą wersji . W ten sposób poprawna konfiguracja projektu i zależności będzie dostępna dla każdego. Z drugiej strony wszyscy programiści będą musieli ustawić swoje środowisko dokładnie w taki sam sposób, w jaki definiujesz je w plikach konfiguracyjnych.
2. Jeśli używasz czegoś takiego jak Maven lub Gradle: poprawnie skonfiguruj te narzędzia i nie utrzymuj katalogu pod kontrolą wersji . Właściwie wszystkie informacje zawarte w plikach konfiguracyjnych powinny być przechowywane w plikach Maven / Gradle. Następnie pozwól swoim programistom skonfigurować IDE w zależności od środowiska. W ten sposób używanie Eclipse, IntelliJ, Linuxa, Windowsa ... nie będzie już problemem.

OK, więc po kilku odpowiedziach „Tak” i „Nie” dodaję odpowiedź „Tak i nie” :)

Problem polega na tym, że .ideajest używany zarówno do konfiguracji kompilacji projektu (deklaracja zależności), jak i ustawień projektu (inspekcje itp.).

Na pewno nie chcesz używać swojego IDE do konfiguracji kompilacji, ale możesz chcieć udostępnić ustawienia zespołowi. Dlatego trzeba ignorować tylko część .ideazawartości (jak librariesfolderu i modules.xmlpliku), ale trzymać innych w kontroli wersji (na przykład copyright, dictionariesi inspectionProfilesfoldery i pliki w .ideaniczym dynamic.xml, codeStyleSettings.xmlitp).

Obowiązuje koncepcja zachowania konfiguracji projektu w VC. Zrobiłem to z moim zespołem, ponieważ wszyscy nasi programiści używali PHPStorm w naszych projektach, więc sensowne było zachowanie wspólnej konfiguracji ... w koncepcji. Chcieliśmy użyć tych samych plików słowników, tych samych standardowych reguł kodowania i tej samej konfiguracji wtyczek.

Powodem, dla którego kwalifikuję to jako „w koncepcji”, są problemy z folderem .idea JetBrains, które sprawiły, że nie mogliśmy go używać. Prawdopodobnie były to problemy, których można było uniknąć lub naprawić, ale nie było dla nas jasne, jak zrobić to dobrze i uważamy, że jest to wina JetBrains, ponieważ jako programiści nie mamy czasu ani chęci szukania rozwiązań, jak zrobić nasze IDE działa poprawnie.

Biorąc to pod uwagę, problemy były następujące:

• Symlinking folderów projektu nie działa prawidłowo. Kiedy konfiguruję swoje projekty, umieszczam je w katalogu domowym. Odkryliśmy, że projekt został skonfigurowany tak, aby używał dokładnego dowiązania symbolicznego, a nie tylko traktował go jak konkretny katalog. Oznacza to, że jeśli inny programista zachowa swój projekt w innym miejscu lub po prostu nie użyje dowiązań symbolicznych, w nawigatorze projektu zniknie cały katalog, ponieważ szuka on dosłownie dowiązania symbolicznego. Co gorsza, nigdy nie mogłem znaleźć tej wartości ścieżki w konfiguracji. Nie mogliśmy znaleźć dokładnej konfiguracji w plikach tworzących nasz folder .idea.
• Pliki definicji są domyślnie podzielone na partycje dla użytkowników. Oznacza to, że jeśli chcę dodać słowo do mojego słownika, zostanie ono wymienione jako definicja dla mnie, jgreathouse, ale inni użytkownicy będą mieli własną sekcję definicji. Oznaczone słowa będą nadal wyświetlane jako błąd w pisowni dla innych użytkowników. To nie jest pożądane. Powodem dodania go do mojego pliku definicji jest to, że IDE jest nieprawidłowe. Chcę, aby te definicje były intuicyjnie udostępniane innym użytkownikom.
• Koledzy ciągle nadpisywali konfiguracje, ponieważ ich IDE nadpisywało konfiguracje ich konfiguracją znajdującą się w pamięci. Chodzi mi o to, że programista pracowałby i scaliłby swoje repozytorium od początku, które zawierałoby zmianę konfiguracji projektu, zamiast zmiany konfiguracji IDE, a nawet dając im wybór, automatycznie nadpisze konfigurację .idea z aktualna konfiguracja ich IDE w pamięci. Moim zdaniem sprawia to, że konfiguracja .idea jest bezużyteczna jako konfiguracja współdzielona. Aby obejść ten problem, deweloper musiałby dosłownie zamknąć to wystąpienie swojego IDE, ściągnąć repozytorium i ponownie otworzyć IDE. Nie ma sensu utrzymywać wspólnej konfiguracji, jeśli IDE natychmiast nadpisze ją konfiguracją znajdującą się w pamięci. To'

Robiłem tego typu współdzielone konfiguracje IDE w VC wcześniej z Visual Studio i Netbeans i zawsze było dobrze; ale z .idea wydaje się po prostu bezużyteczny, co jest rozczarowujące. Chciałabym, żeby JetBrains go opanował i sprawił, że będzie to lepsze doświadczenie użytkownika.