Czy powinienem utrzymywać pliki projektu, takie jak .project, .classpath, .settings, pod kontrolą wersji (np. Subversion, GitHub, CVS, Mercurial itp.)?
Odpowiedzi:
Chcesz zachować kontrolę wersji wszelkich przenośnych plików ustawień ,
co oznacza:
Każdy plik, który nie ma w sobie ścieżki bezwzględnej.
To obejmuje:
Ogólna reguła dla mnie:
musisz być w stanie załadować projekt do obszaru roboczego i mieć w nim wszystko, czego potrzebujesz, aby prawidłowo skonfigurować go w swoim IDE i rozpocząć pracę w ciągu kilku minut.
Żadnej dodatkowej dokumentacji, stron wiki do przeczytania lub nie.
Załaduj, skonfiguruj, idź.
Pliki .project i .classpath tak. Nie przechowujemy jednak naszych ustawień IDE w kontroli wersji. Istnieje kilka wtyczek, które nie radzą sobie dobrze z utrwalaniem ustawień i odkryliśmy, że niektóre ustawienia nie były zbyt przenośne z jednej maszyny deweloperskiej na drugą. Więc zamiast tego mamy stronę Wiki, która podkreśla kroki wymagane przez programistę do skonfigurowania swojego IDE.
Są to pliki, które uważam za wygenerowane i jako takie nigdy nie poddaję ich kontroli wersji. Mogą się one różnić w zależności od maszyny i od dewelopera do programisty, na przykład gdy ludzie mają zainstalowane różne wtyczki Eclipse.
Zamiast tego używam narzędzia do budowania (Maven), które może generować początkowe wersje tych plików, gdy wykonujesz nowe pobranie.
Jestem rozdarty między dwiema opcjami.
Z jednej strony uważam, że każdy powinien mieć swobodę korzystania z zestawu narzędzi programistycznych, z którymi jest najbardziej produktywny, o ile wszystkie artefakty źródłowe są przechowywane w kontroli wersji, a skrypt kompilacji (np. ANT lub Maven) zapewnia zgodność ze standardami przez określanie dokładnie, którego JDK użyć, od których wersji bibliotek stron trzecich ma polegać, sprawdzanie stylu (np. checkstyle) i uruchamianie testów jednostkowych itp.
Z drugiej strony myślę, że tak wiele osób korzysta z tych samych narzędzi (np. Eclipse) i często dużo lepiej jest znormalizować niektóre rzeczy w czasie projektowania niż w czasie kompilacji - na przykład Checkstyle jest o wiele bardziej użyteczny jako wtyczka Eclipse niż jako zadanie ANT lub Maven - lepiej ujednolicić zestaw narzędzi programistycznych i wspólny zestaw wtyczek.
Pracowałem nad projektem, w którym wszyscy używali dokładnie tego samego JDK, tej samej wersji Mavena, tej samej wersji Eclipse, tego samego zestawu wtyczek Eclipse i tych samych plików konfiguracyjnych (np. Profile Checkstyle, reguły formatowania kodu itp.). Wszystkie z nich były przechowywane w kontroli źródła - .project, .classpath i wszystko w folderze .settings. Ułatwiało to życie w początkowych fazach projektu, kiedy ludzie nieustannie dostosowywali zależności lub proces kompilacji. Pomogło to również niezmiernie podczas dodawania nowych starterów do projektu.
Podsumowując, uważam, że jeśli nie ma zbyt wielu szans na wojnę religijną, należy ustandaryzować podstawowy zestaw narzędzi programistycznych i wtyczek oraz zapewnić zgodność wersji w swoich skryptach kompilacji (na przykład wyraźnie określając wersję Java). Nie myśl, że przechowywanie JDK i instalacji Eclipse w kontroli źródła przynosi wiele korzyści. Wszystko inne, co nie jest pochodnym artefaktem - w tym pliki projektu, konfiguracje i preferencje wtyczek (szczególnie formatowanie kodu i reguły stylu) - powinno przejść do kontroli źródła.
PS Jeśli używasz Mavena, istnieje argument za twierdzeniem, że pliki .project i .classpath są pochodnymi artefaktami. Dzieje się tak tylko wtedy, gdy generujesz je za każdym razem, gdy robisz kompilację i jeśli nigdy nie musiałeś ich modyfikować ręcznie (lub nieumyślnie zmieniać ich przez zmianę niektórych preferencji) po wygenerowaniu ich z POM
Nie, ponieważ mam tylko pliki kontroli wersji, które są potrzebne do zbudowania oprogramowania. Poza tym poszczególni programiści mogą mieć własne ustawienia specyficzne dla projektu.
Nie, jestem ciężkim użytkownikiem Mavena i używam Q dla Eclipse wtyczki która tworzy i aktualizuje pliki .project i .classpath. W przypadku innych rzeczy, takich jak ustawienia wtyczek, zwykle mam na ten temat plik README lub stronę Wiki.
Również ci, z którymi pracowałem, którzy wolą inne IDE, po prostu używają wtyczek Maven do generowania plików potrzebnych do utrzymania ich (i siebie) szczęśliwych.
Przypuszczam, że to wszystko jest opinia - ale najlepsze praktyki na przestrzeni lat wskazują, że pliki specyficzne dla danego IDE nie powinny być przechowywane w kontroli źródła, chyba że cała Twoja organizacja jest ustandaryzowana na jednym IDE i nigdy nie zamierzasz zmieniać.
Tak czy inaczej, zdecydowanie nie chcesz zapisywać ustawień użytkownika - a .project może zawierać ustawienia, które są naprawdę specyficzne dla programisty.
Zalecam użycie czegoś takiego jak Maven lub Ant jako standardowego systemu kompilacji. Każdy programista może skonfigurować ścieżkę klas w swoim IDE w ciągu kilku sekund.
Chociaż generalnie zgadzam się na podejście „nie wersjonuj wygenerowanych plików”, mamy z tym problemy i musimy się cofnąć.
Uwaga: Interesuje mnie również odpowiedź VonC , szczególnie kwestia „Uzyskaj Eclipse w ciągu kilku minut”. Ale to nie jest dla nas decydujące.
Nasz kontekst to Eclipse + Maven, używając wtyczki m2eclipse. Mamy wspólne środowisko programistyczne z jak największą liczbą wspólnych katalogów. Ale czasami zdarza się, że ktoś spróbuje wtyczki, zmieni małe rzeczy w konfiguracji lub zaimportuje drugi obszar roboczy dla innej gałęzi ...
Nasz problem polega na tym, że generowanie .project odbywa się podczas importowania projektu w Eclipse, ale nie jest później aktualizowane we wszystkich przypadkach . To smutne i prawdopodobnie nie jest trwałe, ponieważ wtyczka m2eclipse ulegnie poprawie, ale teraz to prawda. W efekcie otrzymujemy różne konfiguracje. To, co mieliśmy dzisiaj, było takie: kilka natur zostało dodanych do wielu projektów na jakiejś maszynie, która wtedy zachowywała się znacznie inaczej :-(
Jedynym rozwiązaniem, jakie widzimy, jest wersja pliku .project (aby uniknąć ryzyka, zrobimy to samo dla .classpath i .settings). W ten sposób, gdy jeden programista zmieni swój pom, lokalne pliki zostaną zaktualizowane za pomocą m2eclipse, wszystkie zostaną zatwierdzone razem, a inni programiści zobaczą wszystkie zmiany.
Uwaga: w naszym przypadku używamy względnych nazw plików, więc nie mamy problemu z udostępnieniem tych plików.
Tak więc, odpowiadając na twoje pytanie, mówię tak, zatwierdź te pliki.
Lubiłem też:
Wygląda na to, że te pliki projektu mogą się zmieniać w czasie podczas pracy nad projektem, więc tak, umieszczam je pod kontrolą wersji.
Używamy IntelliJ IDEA i przechowujemy wersje „.sample” projektu (.ipr) i plików modułów (.iml) pod kontrolą wersji.
Nieco większą rzeczą jest udostępnianie i ponowne wykorzystywanie niż przechowywanie wersji, IMHO. Ale jeśli zamierzasz udostępniać te konfiguracje, jakie jest lepsze miejsce na ich umieszczenie niż repozytorium, tuż obok wszystkiego innego.
Niektóre zalety współdzielonych i wersjonowanych plików projektu:
Zauważ, że w IDEA te pliki zawierają konfiguracje, takie jak: jakie są katalogi „source” i „test source”; wszystko o zależnościach zewnętrznych (gdzie znajdują się pliki jar bibliotek, a także powiązane źródła lub javadocs); opcje kompilacji itp. To jest coś, co nie różni się w zależności od programisty (nie zgadzam się z tym dość mocno). IDEA przechowuje bardziej osobiste ustawienia IDE w innym miejscu, a także wszelkie konfiguracje wtyczek. (Nie znam zbyt dobrze Eclipse; to może być zupełnie inne lub nie).
Zgadzam się z tą odpowiedzią, która mówi:
Musisz być w stanie załadować projekt do obszaru roboczego i mieć w nim wszystko, czego potrzebujesz, aby poprawnie skonfigurować go w swoim IDE i rozpocząć pracę w ciągu kilku minut. [...] Załaduj, ustaw, idź.
I tak to mamy dzięki wersjonowanym plikom projektu.