Ta strona GitPro ładnie podsumowuje konsekwencje aktualizacji podmodułu git
Po uruchomieniu git submodule updatesprawdza konkretną wersję projektu, ale nie w ramach oddziału. Nazywa się to posiadaniem odłączonej głowy - oznacza to, że plik HEAD wskazuje bezpośrednio na zatwierdzenie, a nie na symboliczne odniesienie.
Problem polega na tym, że generalnie nie chcesz pracować w odłączonym środowisku głowy, ponieważ łatwo jest utracić zmiany .
Jeśli wykonasz początkową aktualizację podmodułu, zatwierdź w tym katalogu podmodułów bez tworzenia gałęzi, w której chcesz pracować, a następnie ponownie uruchom aktualizację podmodułu git z superprojektu bez zatwierdzania w międzyczasie, Git nadpisze twoje zmiany bez powiadomienia. Technicznie nie stracisz pracy, ale nie będziesz mieć do niej gałęzi, więc będzie to trochę trudne do odzyskania.
Uwaga marzec 2013:
Jak wspomniano w „ Śledzenie podmodułu git najnowsze ”, teraz podmoduł (git1.8.2) może śledzić gałąź.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
Zobacz „ git submodule update --remotevsgit pull ”.
MindTooth „s odpowiedź zilustrować ręczną aktualizację (bez lokalnej konfiguracji):
git submodule -q foreach git pull -q origin master
W obu przypadkach spowoduje to zmianę odniesień do podmodułów ( gitlink , specjalny wpis w nadrzędnym indeksie repo ) i konieczne będzie dodanie, zatwierdzenie i przekazanie wspomnianych referencji z głównego repozytorium.
Następnym razem, gdy sklonujesz to repozytorium nadrzędne, zapełni ono podmoduły, aby odzwierciedlić te nowe odwołania SHA1.
Pozostała część tej odpowiedzi szczegółowo opisuje klasyczną funkcję submodułu (odniesienie do ustalonego zatwierdzenia, które jest najważniejszym punktem koncepcji submodułu).
Aby uniknąć tego problemu, utwórz gałąź podczas pracy w katalogu submodułów z git checkout -b work lub czymś równoważnym. Gdy wykonasz aktualizację podmodułu po raz drugi, nadal będzie ona cofać twoją pracę, ale przynajmniej masz wskaźnik, do którego możesz wrócić.
Przełączanie gałęzi z submodułami może być również trudne. Jeśli utworzysz nową gałąź, dodaj tam moduł podrzędny, a następnie przełącz się z powrotem do gałęzi bez tego modułu, nadal masz katalog modułów podrzędnych jako katalog bez śledzenia:
Aby odpowiedzieć na twoje pytania:
czy mogę tworzyć gałęzie / modyfikacje i używać push / pull tak, jak w przypadku zwykłych repozytoriów, czy też jest coś, na co należy uważać?
Możesz utworzyć gałąź i modyfikacje push.
OSTRZEŻENIE (z samouczka Git Submodule ): Zawsze publikuj (wypychaj) zmianę podmodułu przed publikowaniem (wypychaj) zmiany do superprojektu, który się do niej odwołuje. Jeśli zapomnisz opublikować zmianę submodułu, inni nie będą mogli sklonować repozytorium.
w jaki sposób miałbym przejść do zatwierdzonego podmodułu, zatwierdzając od powiedzmy (otagowano) 1.0 do 1.1 (nawet jeśli nagłówek oryginalnego repo jest już w wersji 2.0)
Strona „ Zrozumienie submodułów ” może pomóc
Podmoduły Git są implementowane przy użyciu dwóch ruchomych części:
.gitmodulesplik i- specjalny rodzaj drzewa.
Te razem triangulują konkretną wersję konkretnego repozytorium, która jest wyewidencjonowana w określonej lokalizacji w twoim projekcie.
Ze strony podmodułu git
nie można modyfikować zawartości submodułu z poziomu głównego projektu
100% poprawność: nie można modyfikować submodułu, odwołać się tylko do jednego z jego zatwierdzeń.
Dlatego modyfikując submoduł z głównego projektu, wykonujesz:
- trzeba zatwierdzić i pchnąć w podmodule (do modułu nadrzędnego), oraz
- następnie przejdź do głównego projektu i ponownie zatwierdzaj (aby ten główny projekt odwoływał się do nowo zatwierdzonego modułu podrzędnego, który właśnie utworzyłeś i przekazałeś)
Podmoduł umożliwia opracowanie podejścia opartego na komponentach , gdzie główny projekt odnosi się tylko do określonych zatwierdzeń innych komponentów (tutaj „inne repozytoria Git zadeklarowane jako podmoduły”).
Podmoduł jest znacznikiem (zatwierdzeniem) w innym repozytorium Git, które nie jest związane głównym cyklem rozwoju projektu: to („inne” repozytorium Git) może ewoluować niezależnie.
Do głównego projektu należy wybranie z tego drugiego repozytorium dowolnego potrzebnego zatwierdzenia.
Jeśli jednak chcesz, dla wygody , zmodyfikować jedną z tych podmodułów bezpośrednio z głównego projektu, Git pozwala to zrobić, pod warunkiem, że najpierw opublikujesz te modyfikacje podmodułu w oryginalnym repozytorium Git, a następnie zatwierdzisz swój główny projekt, odnosząc się do nowa wersja wspomnianego modułem.
Ale główna idea pozostaje: odniesienie do konkretnych komponentów, które:
- mają swój własny cykl życia
- mają własny zestaw tagów
- mają własny rozwój
Lista konkretnych zatwierdzeń, do których się odwołujesz w głównym projekcie, określa twoją konfigurację (na tym właśnie polega Zarządzanie konfiguracją , englobowanie zwykłego systemu kontroli wersji )
Jeśli komponent można naprawdę opracować w tym samym czasie, co główny projekt (ponieważ każda modyfikacja w głównym projekcie wymagałaby modyfikacji podkatalogu i odwrotnie), byłby to już „podmoduł”, ale scalanie poddrzewa (przedstawione również w pytaniu Przenoszenie starszej bazy kodu z CVS do repozytorium rozproszonego ), łącząc ze sobą historię dwóch repozytoriów Git.
Czy to pomaga zrozumieć prawdziwą naturę submodułów Git?