Układ repozytorium GIT dla serwera z wieloma projektami

Jedną z rzeczy, które lubię w sposobie skonfigurowania Subversion jest to, że mogę mieć jedno główne repozytorium z wieloma projektami. Kiedy chcę pracować nad projektem, mogę sprawdzić tylko ten projekt. Lubię to

\main
    \ProductA
    \ProductB
    \Shared

następnie

svn checkout http://.../main/ProductA

Jako nowy użytkownik git chcę zapoznać się z najlepszymi praktykami w tej dziedzinie, zanim zdecyduję się na określony przepływ pracy. Z tego, co przeczytałem do tej pory, git przechowuje wszystko w jednym folderze .git w katalogu głównym drzewa projektu. Mogłem więc zrobić jedną z dwóch rzeczy.

1. Skonfiguruj osobny projekt dla każdego produktu.
2. Skonfiguruj jeden ogromny projekt i przechowuj produkty w podfolderach.

Istnieją zależności między produktami, więc pojedynczy ogromny projekt wydaje się odpowiedni. Będziemy używać serwera, na którym wszyscy programiści będą mogli udostępniać swój kod. Mam już to działające przez SSH i HTTP i tę część, którą kocham. Jednak repozytoria w SVN mają już wiele GB, więc przeciąganie po całym repozytorium na każdym komputerze wydaje się złym pomysłem - zwłaszcza, że ​​płacimy za nadmierną przepustowość sieci.

Wyobrażam sobie, że repozytoria projektów jądra Linuksa są równie duże, więc musi istnieć właściwy sposób radzenia sobie z tym za pomocą Gita, ale jeszcze tego nie rozgryzłem.

Czy istnieją wskazówki lub najlepsze praktyki dotyczące pracy z bardzo dużymi repozytoriami obejmującymi wiele projektów?

Wytyczne są proste, jeśli chodzi o ograniczenia Gita :

• jedno repozytorium na projekt
• główny projekt z podmodułami .

Chodzi o to, aby nie przechowywać wszystkiego w jednym gigantycznym repozytorium git, ale zbudować małe repozytorium jako główny projekt, który będzie odnosił się do odpowiednich zatwierdzeń innych repozytoriów, z których każdy będzie reprezentował własny projekt lub wspólny komponent.

W PO Paul Alexander komentarze :

Brzmi to podobnie do wsparcia „zewnętrznego” zapewnianego przez subversion.
Wypróbowaliśmy to i stwierdziliśmy, że ciągłe aktualizowanie odniesień do wersji w zewnętrznych programach jest niezwykle kłopotliwe, ponieważ projekty są opracowywane równolegle ze wzajemnymi zależnościami. Czy jest inna opcja?

@Paul: tak, zamiast aktualizować wersję z głównego projektu, możesz:

• rozwijać swoje podprojekty bezpośrednio z głównego projektu (jak wyjaśniono w „ True Nature of submodules ”),
• lub odwołujesz się w repozytorium pośrednim origindo tego samego repozytorium, które zostało opracowane w innym miejscu: stamtąd wystarczy wyciągnąć z tego repozytorium zmiany wprowadzone gdzie indziej.

W obu przypadkach nie możesz zapomnieć o zatwierdzeniu głównego projektu, aby zapisać nową konfigurację. Brak właściwości „zewnętrznej” do zaktualizowania w tym miejscu. Cały proces jest znacznie bardziej naturalny.

Szczerze mówiąc, brzmi to jak prawdziwy ból, a wszystko, co wymaga od programistów ręcznego wykonania za każdym razem, będzie po prostu regularnym źródłem błędów i konserwacji.
Przypuszczam, że zajrzę się automatyzacją tego za pomocą niektórych skryptów w super projekcie.

Odpowiedziałem:

Szczerze mówiąc, możesz mieć rację ... to znaczy do najnowszej wersji Gita 1.7.1 .
git diffi git statusobaj nauczyli się uwzględniać stany submodułów, nawet jeśli są wykonywane z głównego projektu.
Po prostu nie możesz przegapić modyfikacji submodułu.

Biorąc to pod uwagę:

• moduły podrzędne różnią się od zewnętrznych SVN: zobacz „ Dlaczego podmoduły git są niekompatybilne z zewnętrznymi svn? ”
• zarządzanie modułami podrzędnymi może być trudne: zobacz „ Jak dokładnie działa moduł podrzędny git? ”.

GitSlave umożliwia zarządzanie kilkoma niezależnymi repozytoriami jako jednym. Każdym repozytorium można manipulować za pomocą zwykłych poleceń git, podczas gdy gitslave pozwala dodatkowo uruchomić polecenie dla wszystkich repozytoriów.

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Repo-per-project ma zalety dzięki komponowaniu i uproszczonym kompilacjom za pomocą narzędzi takich jak Maven. Repo-per-project dodaje ochronę, ograniczając zakres tego, co zmienia deweloper - w zakresie błędnych zatwierdzeń śmieci.