Co powinienem zawrzeć w moim repozytorium z projektów IDE

10

Chcę dodać projekt, który w tym przypadku jest tworzony w Netbeans, ale to pytanie jest ogólne dla większości IDE. Po prostu co powinienem zawrzeć w moim repozytorium. Na przykład Netbeans tworzy folder nbproject, eclipse tworzy folder .settings itp. Jeśli powinienem dołączyć je do mojego repozytorium, jakie są zalety / wady włączenia lub nie uwzględnienia ustawień specyficznych dla projektu.

W tym przypadku jest to projekt osobisty, więc nie wyobrażam sobie, aby inni mogli zacząć nad nim pracować, ale byłoby miło dodać absolutne minimum ustawień projektu, aby sam projekt mógł łatwo rozpocząć pracę na różnych komputerach.

Daniel Figueroa
źródło
Zastanów się nad narzędziami takimi jak maven z wtyczką Eclipse (lub inną ide) do konfigurowania odpowiedniego środowiska, a nie własnego.
@MichaelT Bardzo przepraszam, ale tak naprawdę nie podążam, czy mógłbyś to rozwinąć?
Daniel Figueroa
Korzystanie z narzędzia kompilacji i skonfigurowanie środowiska kompilacji dla ide pozwala mieć pewność, że konfiguracja jest taka sama bez względu na platformę (lub ide). Nawet deweloperzy solo mają wiele środowisk (ide vs build). Upraszcza to pytanie do odpowiedzi, na którą „nie wpisuj niczego, co jest specyficzne dla twojego środowiska, ponieważ są one generowane”. - to samo uzasadnienie, którego nie sprawdzasz w klasach .java generowanych przez jaxb, ale raczej instrukcje (build.xml lub .pom) jak je zbudować.
Jeśli jest „oryginalny”, należy wykonać kopię zapasową. Jeśli to się zmieni, a te wymagają śledzenia i są oryginalne, należy je kontrolować. Złap - jak ustrukturyzować repozytorium tak, aby źródło pozostało Twoim źródłem, podczas gdy konfiguracje łańcucha narzędzi nie zanieczyszczają repozytorium źródłowego. To samo dotyczy zasobów, takich jak obrazy, dźwięk i wideo ....
mattnz

Odpowiedzi:

4

To naprawdę zależy od tego, jakie są dane, i powinno być ustalane indywidualnie dla każdego przypadku, być może nawet dla poszczególnych plików. Spójrz na zawartość tych plików. Najczęściej możesz powiedzieć, co one oznaczają. Rzeczy takie jak położenie i rozmiar okien IDE to coś, czego nie chcesz w kontroli źródła.

Ale niektóre pliki projektu IDE są istotnymi metadanymi projektu. Nie znam dobrze Netbeans, ale w przypadku zaćmienia plik .project informuje IDE, jak nazywa się projekt, że jest to projekt internetowy Java itp., A plik .classpath zawiera informacje o folderach źródłowych i bibliotekach. Niektóre pliki w katalogu .settings mogą być równie ważne, np. Org.eclipse.core.resources.prefs zawiera informacje o tym, jakie kodowanie należy zastosować dla jakich plików.

Jako metadane projektu, te rzeczy bardzo zasługują na kontrolę wersji.

Niektóre IDE mogą importować metadane projektu z innych IDE. Byłoby jeszcze lepiej mieć go w formie niepowiązanej z konkretnym IDE.

W przypadku Javy istnieje coś takiego: Maven . Nakłada silne konwencje na strukturę projektu i pozwala określić metadane projektu (takie jak zależności bibliotek) w jednym punkcie (plik o nazwie pom.xml, który znajduje się w głównym katalogu projektu i, oczywiście, w kontroli źródła). Istnieją wtyczki, które następnie tworzą pliki projektu IDE z konfiguracji Maven i inne, które mogą zautomatyzować proces kompilacji projektu lub zrobić wszystko. Czasami wydaje się, że sprawia, że ​​sprawy stają się niepotrzebnie skomplikowane i nauka zajmuje trochę czasu, ale korzyści na ogół są tego warte.

Michael Borgwardt
źródło
1
jeśli się nie mylę, Maven jest niezależna od IDE. Jeśli tak, to skoro zawiera ustawienia / metadane projektów, to zdecydowanie powinien zawierać w repozytorium, ale nie „pliki projektów IDE”, do których OP wyraźnie się odnosi.
Bleeding Fingers,
@ hus787: Chodzi mi o to, że te metadane są bardzo ważne, aby znaleźć się w repozytorium, i chociaż świetnie jest, gdy masz je w postaci niezależnej od IDE, ale nie jest tak, ale lepiej jest je mieć niż nie posiadać to.
Michael Borgwardt,
2

To naprawdę zależy od tego, jakie informacje chciałbyś mieć w repozytorium. Jeśli chcesz wszystko od razu do tego, które pliki miałeś otwarte i edytowałeś w momencie zatwierdzenia, a ty jesteś jedynym, który korzysta z repozytorium, śmiało i zatwierdzaj to wszystko, ale wiedz, że to może nie działać na innym komputerze .

Jeśli chcesz mieć możliwość udostępniania swojego kodu innym osobom, które mogą nie używać tego samego IDE, po prostu zatwierdź sam kod bez implementacji specyficznej dla projektu.

Jeśli wiesz, że wszyscy używają tego samego IDE, prawdopodobnie możesz dołączyć wszystko, co nie jest specyficzne dla komputera, czyli dowolne ustawienia plików / folderów tylko dla samego IDE, w ten sposób mogą już mieć możliwość importowania projektu jako IDE tego oczekuje.

Ampt
źródło
2

Artefakty, które pomagają swoim rozwoju i nie mają zastosowania do budowy / release lub sam projekt powinien nie być uwzględnione. Repozytorium powinno być czyste i uporządkowane i zawierać tylko te rzeczy, które są istotne dla projektu, a nie środowisko . Repo powinno być nieświadome twoich nawyków. A po drugie, niepotrzebnie Cię to zepsuje, gdy zrobisz coś podobnego do git status... ale hej, nigdy nie wprowadziłem żadnych zmian ... ahh zignoruj ​​to.

Podam bardziej praktyczny przykład (użyję gittutaj jako narzędzia):

Nigdy nie chciałbyś, aby (rekurencyjny) submoduł w twoim głównym repozytorium zawierał elementy specyficzne dla IDE (może to również kolidować z głównym środowiskiem projektu), ponieważ zależy ci tylko na kodzie, który został napisany przez kogoś innego (lub ciebie) i jest użytkowania w ramach bieżącego projektu. Nie środowisko, w którym zostało opracowane. Prawdopodobnie nie chcesz tego też robić komuś innemu.

Aby móc użyć ustawień na innym komputerze, sugeruję zagłębić się w IDE i sprawdzić, jakie wsparcie zapewnia dla takich rzeczy. Emacs ma initrównież serwer Emacs. Możesz też utworzyć niestandardowe makro lub skrypt ( .sh), który wykonuje konfigurację automatycznie.

Krwawiące palce
źródło
-1: całkowicie się nie zgadzam. Mogą to być bardzo ważne i przydatne informacje, a Twoje repozytorium zdecydowanie powinno zawierać takie informacje.
Michael Borgwardt,
@MichaelBorgwardt co jeśli OP planuje później przejść na inne IDE. Jak te ustawienia specyficzne dla IDE projektu będą rozumiane w drugim? Przykład byłby bardzo mile widziany.
Bleeding Fingers,
Niektóre IDE mogą importować metadane projektu z innych IDE. Nawet jeśli nie mogą, pliki te są zazwyczaj czytelne dla ludzi, a ich posiadanie jest lepsze niż ich brak.
Michael Borgwardt,
A co się stanie, jeśli całkowicie zubożysz swój obszar roboczy (co mi się ostatnio przydarzyło) i nie możesz cofnąć zmian poprzez ręczne przywrócenie ustawień do poprzedniego stanu? Prawdopodobnie zaoszczędziłem godziny, ponieważ obszar roboczy został zameldowany. Nie wspominając o tym, że w niektórych IDE obszar roboczy będzie zawierał takie rzeczy, jak szablony kodu, których konfigurowanie ręcznie za każdym razem byłoby ogromnym problemem.
Amy Blankenship
@AmyBlankenship, o to mi chodzi, to twoja przestrzeń robocza, w jaki sposób możesz być pewien, że nie przeszkadza innym (przyciągają i nagle ich przestrzeń robocza zostaje zastąpiona twoją), lepiej trzymać te rzeczy w oddzielnym lokalnym oddziale lub możesz użyć mercurial w swoim osobistym obszarze roboczym VC i git w projekcie VC. Jeśli chodzi o szablony kodu, myślę, że twoje IDE nie jest wystarczająco dojrzałe (lub nie zostało jeszcze właściwie zbadane) i jeśli mówisz, że szablony są specyficzne dla projektu, to chyba powinieneś szukać wzorców w kodzie.
Bleeding Fingers
1

Jeśli jest to projekt osobisty, mówię, że przechowuj ustawienia w kontroli źródła. Osobiście nic nie zabija mojej motywacji bardziej do projektu niż ponowne stworzenie środowiska programistycznego.

Gdy zaangażowanych jest więcej osób, nie poddaję tych kontroli źródła. W moim zespole używamy kombinacji IntelliJ, Sublime Text i Eclipse. Pliki IDE po prostu dodają bałaganu i powodują pobieranie zatwierdzeń do tych plików od innych osób dla IDE, którego nie używasz.

Twój projekt i tak nie powinien być zależny od IDE. Serwer kompilacji nie uruchamia się w Eclipse w celu skompilowania produktu, więc powinien już być wolny od IDE. Bardziej drobna uwaga: eliminuje organizację osobistą w ramach projektu. Na przykład w IntelliJ lubię używać wielu modułów w naszym projekcie. Nikt inny korzystający z IntelliJ nie martwi się tym, ponieważ nie przechowujemy plików .iml (modułu).

Jeśli twój zespół używa tego samego IDE, to lepiej, ale ktoś popełni zły wpis .classpath, ponieważ użył ścieżki bezwzględnej. Teraz wszyscy używający IDE martwią się tym.

Jasne, wadą jest to, że konfiguracja jest większa, gdy ktoś sprawdza projekt. Myślę, że warto. Używamy Ivy do zarządzania zależnościami i mamy informacje na temat konfiguracji, zależności itp. Mimo tego z góry uważam, że warto trzymać ustawienia IDE poza kontrolą źródła.

Kryptic
źródło