Moduły podrzędne Git
Moduły podrzędne w Git umożliwiają przechowywanie repozytorium Git jako katalogu podrzędnego innego repozytorium Git. Moduły podrzędne są po prostu odniesieniem do innego repozytorium w konkretnym momencie w czasie. Umożliwiają one włączenie do repozytorium Git kodu zewnętrznego i śledzenie jego historii wersji.
Czym jest moduł podrzędny Git?
Często repozytorium kodu zależy od kodu zewnętrznego. Ten kod zewnętrzny można uwzględnić na kilka różnych sposobów. Kod zewnętrzny można bezpośrednio skopiować i wkleić do głównego repozytorium. Wadą tej metody jest utrata wszelkich wcześniejszych zmian wprowadzonych w zdalnym repozytorium. Inną metodą włączania kodu zewnętrznego jest użycie systemu zarządzania pakietami konkretnego języka, takiego jak Ruby Gems lub NPM. Wadą tej metody jest konieczność zarządzania instalacjami i wersjami we wszystkich miejscach, gdzie wdrażany jest kod pierwotny. Żadna z tych sugerowanych metod włączania nie umożliwia śledzenia modyfikacji ani zmian wprowadzanych w zewnętrznym repozytorium.
Moduł podrzędny Git jest rekordem w repozytorium Git hosta, który wskazuje na konkretny commit w innym repozytorium zewnętrznym. Moduły podrzędne są bardzo statyczne i śledzą jedynie określone commity. Moduły podrzędne nie śledzą referencji ani gałęzi Git i nie są aktualizowane automatycznie podczas aktualizacji repozytorium hosta. Podczas dodawania modułu podrzędnego do repozytorium tworzony jest nowy plik .gitmodules. Plik .gitmodules zawiera metadane na temat mapowania między adresem URL projektu modułu podrzędnego a katalogiem lokalnym. Jeśli repozytorium hosta zawiera wiele modułów podrzędnych, plik .gitmodules będzie zawierał wpis dla każdego modułu podrzędnego.
Kiedy należy użyć modułu podrzędnego Git?
Jeśli chcesz rygorystycznie zarządzać wersjami z uwzględnieniem zależności zewnętrznych, dobrym rozwiązaniem jest wykorzystanie modułów podrzędnych Git. Poniżej znajdziesz kilka najlepszych przypadków użycia modułów podrzędnych Git.
- Gdy komponent zewnętrzny lub projekt podrzędny zmieniają się zbyt szybko lub nadchodzące zmiany spowodują uszkodzenie interfejsu API, możesz dla bezpieczeństwa zablokować kod na konkretnym commicie.
- Gdy masz komponent, który nie jest aktualizowany zbyt często, a chcesz go śledzić jako zależność dostawcy.
- Gdy delegujesz fragment projektu do innej osoby i chcesz zintegrować wykonaną przez nią pracę w konkretnym czasie lub wydaniu. Także tutaj ten sposób sprawdza się wówczas, gdy aktualizacje nie są zbyt częste.
materiały pokrewne
Jak przenieść pełne repozytorium Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
Typowe polecenia w przypadku modułów podrzędnych Git
Dodawanie modułu podrzędnego Git
Polecenie git submodule add służy do dodawania nowego podmodułu do istniejącego repozytorium. Poniższy przykład pozwala utworzyć puste repozytorium i przeanalizować podmoduły Git.
$ mkdir git-submodule-demo
$ cd git-submodule-demo/
$ git init
Initialized empty Git repository in /Users/atlassian/git-submodule-demo/.git/Ta sekwencja poleceń spowoduje utworzenie nowego katalogu git-submodule-demo, jego otwarcie, a następnie zainicjowanie go jako nowego repozytorium. Następnie do tego nowo utworzonego repozytorium dodamy moduł podrzędny.
$ git submodule add https://bitbucket.org/jaredw/awesomelibrary
Cloning into '/Users/atlassian/git-submodule-demo/awesomelibrary'...
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 8 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.Polecenie git submodule add przyjmuje parametr adresu URL, który wskazuje na repozytorium Git. W tym przypadku jako moduł podrzędny dodaliśmy awesomelibrary. Git od razu sklonuje moduł podrzędny. Teraz można sprawdzić bieżący stan repozytorium za pomocą polecenia git status.
$ git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: .gitmodules
new file: awesomelibrarySą teraz dwa nowe pliki w repozytorium .gitmodules oraz w katalogu awesomelibrary. Gdy przyjrzymy się zawartości pliku .gitmodules, widać nowe mapowanie modułu podrzędnego.
[submodule "awesomelibrary"]
path = awesomelibrary
url = https://bitbucket.org/jaredw/awesomelibrary
$ git add .gitmodules awesomelibrary/
$ git commit -m "added submodule"
[main (root-commit) d5002d0] added submodule
2 files changed, 4 insertions(+)
create mode 100644 .gitmodules
create mode 160000 awesomelibraryKlonowanie modułów podrzędnych Git
git clone /url/to/repo/with/submodules
git submodule init
git submodule updatePolecenie git submodule init
Domyślnym sposobem działania polecenia git submodule init jest skopiowanie mapowania z pliku .gitmodules do lokalnego pliku ./.git/config. Takie działanie może wydawać się nadmiarowe i budzić wątpliwości co do przydatności polecenia git submodule init. Jednak polecenie git submodule init ma rozbudowany zakres działania, w którym przyjmuje listę jawnych nazw modułów. Umożliwia to zastosowanie przepływu pracy, w którym aktywowane są tylko konkretne moduły podrzędne potrzebne do pracy nad repozytorium. Bywa to przydatne, gdy w repozytorium znajduje się wiele modułów podrzędnych, ale nie wszystkie one muszą być pobrane, aby można było wykonywać prace.
Przepływy pracy związane z modułami podrzędnymi
Gdy moduły podrzędne zostaną właściwie zainicjowane i zaktualizowane w repozytorium nadrzędnym, będzie można je wykorzystać dokładnie tak samo, jak autonomiczne repozytoria. Oznacza to, że moduły podrzędne mają własne gałęzie i historię. Po wprowadzaniu zmian w module podrzędnym ważne jest, aby je opublikować i zaktualizować referencję do modułu podrzędnego w repozytoriach nadrzędnych. Skorzystajmy z przykładowego modułu awesomelibrary i wprowadźmy pewne zmiany:
$ cd awesomelibrary/
$ git checkout -b new_awesome
Switched to a new branch 'new_awesome'
$ echo "new awesome file" > new_awesome.txt
$ git status
On branch new_awesome
Untracked files:
(use "git add <file>..." to include in what will be committed)
new_awesome.txt
nothing added to commit but untracked files present (use "git add" to track)
$ git add new_awesome.txt
$ git commit -m "added new awesome textfile"
[new_awesome 0567ce8] added new awesome textfile
1 file changed, 1 insertion(+)
create mode 100644 new_awesome.txt
$ git branch
main
* new_awesomeTutaj zmieniliśmy katalog do modułu podrzędnego awesomelibrary. Utworzyliśmy nowy plik tekstowy new_awesome.txt o pewnej zawartości, dodaliśmy ten nowy plik do modułu podrzędnego i zatwierdziliśmy. Teraz z powrotem zmienimy katalogi na repozytorium nadrzędne i sprawdzimy aktualny stan repozytorium nadrzędnego.
$ cd ..
$ git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: awesomelibrary (new commits)
no changes added to commit (use "git add" and/or "git commit -a")
Wykonanie polecenia git status wskazuje, że repozytorium nadrzędne wie o nowych commitach dodanych do modułu podrzędnego awesomelibrary. Nie podaje szczegółów na temat konkretnych aktualizacji, ponieważ to należy do obowiązków repozytoriów modułu podrzędnego. Repozytorium nadrzędne musi jedynie przypiąć moduł podrzędny do commita. Teraz możemy ponownie zaktualizować repozytorium nadrzędne, wykonując polecenie git add i git commit na module podrzędnym. Dzięki temu wszystkie elementy znajdą się w odpowiednim stanie i będą zwierały zawartość lokalną. Jeśli pracujesz w środowisku zespołowym, bardzo ważne jest wypychanie aktualizacji modułu podrzędnego i repozytorium nadrzędnego za pomocą polecenia git push.
Podczas pracy z modułami podrzędnymi częstą przyczyną zamieszania i błędów jest zapominanie o wypychaniu aktualizacji dla użytkowników zdalnych. Jeśli ponownie spojrzymy na prace wykonane w odniesieniu do modułu podrzędnego awesomelibrary, zauważymy, że wypchnęliśmy aktualizacje jedynie do repozytorium nadrzędnego. Inny programista mógłby pobrać najnowsze repozytorium nadrzędne, a ono wskazywałoby na commit awesomelibrary, którego nie można byłoby ściągnąć, ponieważ zapomnieliśmy o wypchnięciu modułu podrzędnego. Spowodowałoby to uszkodzenie repozytorium lokalnego u zdalnych programistów. Aby uniknąć takich błędów, trzeba zawsze pamiętać o zatwierdzeniu i wypchnięciu modułu podrzędnego oraz repozytorium nadrzędnego.
Wnioski
Moduły podrzędne w Git są zaawansowanym sposobem wykorzystania Git jako narzędzia do zarządzania zależnościami zewnętrznymi. Zanim użyjesz modułów podrzędnych, poznaj ich wady i zalety, ponieważ jest to zaawansowana funkcja, której opanowanie przez członków zespołu może wymagać czasu.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
