Alternatywa dla podmodułów Git?

83

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.

  • Czy jest więcej narzędzi do wielu projektów repozytoriów i jak można je porównać?
  • Czy te narzędzia mogą działać w systemie Windows?
Chau Chee Yang
źródło
3
Czy mówisz o strategii scalania poddrzewa Git lub poddrzewie git Avery Pennarun ? Te dwie zasadniczo nie są takie same.
kynan
1
Dobrze przeczytać tutaj codingkilledthecat.wordpress.com/2012/04/28/…
nawfal
3
Zobacz mój nieoficjalny rozwidlenie gitslave , mam nadzieję, że jest bardziej aktywny niż oryginał od 2.0.2.
Joel Purra
1
Istnieje również git-subrepo .
przytulanie

Odpowiedzi:

101

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.

Seth Robertson
źródło
7
Należy zauważyć, że poddrzewo git w tej odpowiedzi odnosi się (jak wspomniano) do strategii scalania poddrzewa Git, a nie do poddrzewa git firmy Avery Pennarun , które zasadniczo nie są tym samym. Ta ostatnia została wyraźnie zaprojektowana, aby umożliwić wnoszenie zmian z powrotem z poddrzewa.
kynan
3
Świetna awaria! Chciałbym zobaczyć, jak to zostało zmienione, aby odróżnić „scalanie poddrzewa” od git-subtree, jak wspomina @kynan.
BrianTheLion
1
@Tobu: Nie uważam zdolności pana do uruchamiania dowolnych poleceń za to samo, co posiadanie zintegrowanej obsługi poleceń git. Zakładam, że mówisz o czymś takim jak 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ć.
Seth Robertson
4
@kynan: oprócz twojego komentarza. Chciałbym zaznaczyć, że poddrzewo git Avery's Pennarun jest teraz dostępne w git 1.7.11 i nowszych.
slatunje
1
@sealTrip: dostępne tak, jak jest 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).
kynan
2

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ą.

Dmitry Linov
źródło
1

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.

Adam Dymitruk
źródło
0

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

svarlamov
źródło
Ten problem nie wygląda dobrze: github.com/exlinc/mdlr/issues/16
rjdkolb
0

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.

taniusz
źródło