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

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.

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.

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.

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.

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.