Czuję, że używanie podmodułów Git jest w jakiś sposób kłopotliwe dla mojego przepływu pracy. Słyszałem o poddrzewie Git i Gitslave.
Odpowiedzi:
To, co jest dla Ciebie najlepsze, zależy od Twoich potrzeb, pragnień i przepływu pracy. W pewnym sensie są półizomorficzne, po prostu niektóre są o wiele łatwiejsze w użyciu niż inne do określonych zadań.
gitslave jest przydatne, gdy kontrolujesz i rozwijasz podprojekty mniej więcej w tym samym czasie co superprojekt, a ponadto, gdy zazwyczaj chcesz otagować, rozgałęzić, wypchnąć, wyciągnąć itp. wszystkie repozytoria w tym samym czasie. gitslave nigdy nie był testowany na znanych mi oknach. Wymaga perla.
git-submodule jest lepszy, gdy nie kontrolujesz podprojektów lub bardziej szczegółowo chcesz naprawić podprojekt w określonej wersji, nawet gdy podprojekt się zmienia. git-submodule jest standardową częścią git i dlatego będzie działać w systemie Windows.
git-subtree zapewnia front-end dla wbudowanej w git strategii scalania poddrzewa. Lepiej jest, gdy wolisz mieć „zunifikowaną” historię git w jednym repozytorium. W przeciwieństwie do strategii scalania poddrzewa, łatwiej jest eksportować zmiany do różnych drzew (katalogów) z powrotem do oryginalnego projektu, ale nie jest to tak automatyczne, jak w przypadku gitslave lub nawet git-submodule.
repo jest teoretycznie podobny do gitslave, ale nie jest tak dobrze udokumentowany dla operacji innych niż android, które znalazłem. Jest dość dedykowany modelowi programistycznemu Google Android i natywnie obsługuje tylko kilka poleceń git (chociaż można uruchamiać dowolne polecenia), a ograniczona obsługa natywna nie obsługuje na przykład scentralizowanego repozytorium do wypychania i sprawdzania gałąź wydaje się dość trudna.
kitenet na mr jest to, czego chcesz używać, jeśli masz wiele systemów kontroli wersji w użyciu, ale ogranicza się głównie do git tylko superprojects ze względu na jej minimalistycznego podejścia. Istnieją sposoby uruchamiania dowolnych poleceń, ale nie są one tak dobrze zintegrowane.
mr run git config ...lub (nawet gorzej) metodzie pliku konfiguracyjnego, która aliasuje określone polecenia do nazw. Oczywiście, jeśli zdajesz sobie sprawę z pewnych funkcji Mr, które nie były od razu widoczne po przeczytaniu strony podręcznika, chciałbym się o tym dowiedzieć.
git/contrib. Zainstaluj w Ubuntu z sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-coredrzewa źródłowego Git ( nie działa z pakietem Git).
Nowym dodatkiem do listy alternatyw jest Git X-Modules . Ma to na celu uniknięcie typowych wad podmodułów Git, jak opisano tutaj . Główna różnica polega na tym, że cała synchronizacja odbywa się po stronie serwera, więc dla użytkowników końcowych jest tylko zwykłe repozytorium Git, które klonują i do którego wysyłają.
Obecnie używam modułów podrzędnych do programowania, a nie tylko do tworzenia powiązań z bibliotekami innych firm. Istnieje kilka sposobów na ułatwienie życia dzięki modułom podrzędnym, zwłaszcza gdy są one źródłem konfliktów scalania lub ponownego bazowania. Spójrz na ls-tree, aby uzyskać 2 zatwierdzenia związane z konfliktem w module podrzędnym. Jest to prawdopodobnie najtrudniejsza część modułów podrzędnych, z którą ludzie mogą sobie poradzić. Na razie skrypty znacznie ułatwią pracę. Przyszłe wersje Gita powinny mieć lepszą natywną obsługę ich obsługi.
Mam nadzieję że to pomoże.
Napotkaliśmy podobny problem podczas korzystania z podmodułów Git w projektach, w których mieliśmy zależności w różnych językach. Aby sobie z nimi poradzić, stworzyliśmy i udostępniliśmy na zasadach open source narzędzie o nazwie MDLR („Modular”), które zapewnia deklaratywne, kontrolowane przez wersję zależności Git z podobną funkcjonalnością do podmodułów Git, ale bez irytującego przepływu pracy. Możesz go zainstalować i zarządzać swoimi zależnościami za pomocą instrukcji / plików do pobrania w repozytorium GitHub
W niektórych przypadkach podobało mi się każde z następujących dwóch prostych podejść:
Zagnieżdżone repozytoria. Jeśli twój projekt oprogramowania ma mechanizm wtyczek, z każdą wtyczką w swoim własnym podkatalogu, sensowne może być git-zignorowanie tych katalogów wtyczek i, w lokalnym systemie plików, umieszczenie każdego z nich we własnym repozytorium git. W ten sposób wszystkie twoje pliki tworzą jedno drzewo katalogów, ale są zarządzane w różnych repozytoriach git. To nie zmyli gita.
Repozytoria dla poszczególnych pakietów. W przypadku projektów oprogramowania, w których używasz pewnego rodzaju systemu zarządzania pakietami kodu źródłowego (gem / bundler, npm, pear itp.) Sensowne może być umieszczenie ponownie używanego kodu w oddzielnych repozytoriach git, a następnie utworzenie z nich pakietów źródłowych, a następnie zainstalować je za pomocą narzędzia do zarządzania pakietami w projekcie nadrzędnym. Repozytorium git twojego projektu nadrzędnego zawierałoby tylko odniesienie do wymaganych pakietów i ich wersji, podczas gdy rzeczywisty kod tych pakietów zostanie zignorowany przez git, tak jak jest to zrobione z wszystkimi innymi pakietami i bibliotekami zewnętrznymi. W porównaniu z repozytoriami zagnieżdżonymi zaproponowanymi powyżej, jest to bardziej złożone podejście, ponieważ pozwala określić, która wersja pakietu ma zostać zainstalowana.