Close

git clone

Przyjrzymy się teraz dokładniej poleceniu git clone. Polecenie git clone jest narzędziem wiersza polecenia systemu Git służącym do wybierania istniejącego repozytorium i tworzenia klona lub kopii takiego repozytorium docelowego. Na tej stronie omówimy rozszerzone opcje konfiguracji i typowe przypadki użycia polecenia git clone. Opisane zagadnienia:

  • Klonowanie repozytorium lokalnego lub zdalnego
  • Klonowanie repozytorium początkowego
  • Częściowe klonowanie repozytoriów za pomocą opcji klonowania płytkiego
  • Składnia adresów URL i obsługiwane protokoły w systemie Git

W przewodniku dotyczącym konfigurowania repozytorium zostały opisane podstawowe przypadki użycia polecenia git clone. Na tej stronie omówimy bardziej złożone scenariusze klonowania i konfiguracji.


Cel: kopia robocza na potrzeby współpracy między repozytoriami


Polecenie git clone to najczęściej stosowana przez użytkowników metoda uzyskania kopii do prac programistycznych po skonfigurowaniu projektu w centralnym repozytorium. Podobnie jak w przypadku polecenia git init klonowanie jest zasadniczo operacją jednorazową. Gdy programista uzyska kopię roboczą, zarządzanie wszystkimi operacjami związanymi z kontrolą wersji oraz współpracą odbywa się z poziomu jego lokalnego repozytorium.

Współpraca między repozytoriami

Trzeba zrozumieć, że koncepcja „kopii roboczej” w systemie Git różni się znacznie od kopii roboczej otrzymywanej poprzez wyewidencjonowanie kodu z repozytorium SVN. W przeciwieństwie do SVN w systemie Git nie ma rozróżnienia na kopię roboczą i centralne repozytorium — są one pełnoprawnymi repozytoriami Git.

To sprawia, że współpraca w Git zasadniczo różni się od współpracy w SVN. Podczas gdy funkcjonowanie SVN opiera się na zależnościach między centralnym repozytorium a kopią roboczą, model współpracy Git bazuje na interakcji między repozytoriami. Zamiast ewidencjonowania kopii roboczej w centralnym repozytorium SVN korzysta się z poleceń push i pull do wypychania lub ściągania commitów z jednego repozytorium do drugiego.

Gałąź Git
materiały pokrewne

Gałąź Git

Logo Bitbucket
POZNAJ ROZWIĄZANIE

Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud

Samouczek Git: współpraca repozytorium z kopią roboczą
Samouczek Git: współpraca między repozytoriami

Oczywiście nic nie stoi na przeszkodzie, aby określonym repozytoriom Git nadać szczególne znaczenie. Można na przykład odtworzyć scentralizowany przepływ pracy przy użyciu systemu Git, określając jedno repozytorium Git jako repozytorium „centralne”. Chodzi o to, że jest to uzyskiwane poprzez zastosowanie pewnej konwencji, a nie wymuszone przez integralną cechę samego systemu kontroli wersji.

Użycie


Polecenie git clone służy przede wszystkim do wskazania istniejącego repozytorium i utworzenia klona lub kopii tego repozytorium w nowym katalogu, w innej lokalizacji. Repozytorium pierwotne może znajdować się w lokalnym systemie plików lub na komputerze zdalnym z dostępem do obsługiwanych protokołów. Polecenie git clone kopiuje istniejące repozytorium Git. Przypomina to operację wyewidencjonowania w SVN, z wyjątkiem tego, że „kopia robocza” jest pełnoprawnym repozytorium Git. Ma swoją własną historię, zarządza własnymi plikami i jest środowiskiem całkowicie odizolowanym od repozytorium pierwotnego.

Dla wygody operacja klonowania powoduje automatyczne utworzenie zdalnego połączenia o nazwie „origin”, które wskazuje na pierwotne repozytorium. Bardzo ułatwia to interakcję z centralnym repozytorium. Takie automatyczne połączenie jest ustanawiane poprzez utworzenie referencji Git do końcówek gałęzi zdalnej w lokalizacji refs/remotes/origin oraz zainicjowanie zmiennych konfiguracyjnych remote.origin.url i remote.origin.fetch.

Przykład ilustrujący użycie polecenia git clone można znaleźć w przewodniku dotyczącym konfigurowania repozytorium. W poniższym przykładzie zaprezentowano, jak uzyskać lokalną kopię centralnego repozytorium przechowywanego na serwerze dostępnym pod adresem example.com przy użyciu nazwy użytkownika SSH „john”:

git clone ssh://john@example.com/path/to/my-project.git 
cd my-project 
# Start working on the project

Pierwsze polecenie inicjuje nowe repozytorium Git w folderze my-project na komputerze lokalnym i wypełnia je zawartością centralnego repozytorium. Następnie za pomocą polecenia „cd” można przejść do projektu i przystąpić do edycji plików, zatwierdzania migawek oraz interakcji z innymi repozytoriami. Należy również zauważyć, że rozszerzenie .git jest pomijane w sklonowanym repozytorium. Wskazuje to, że kopia lokalna nie ma statusu elementu początkowego.

Klonowanie do konkretnego folderu

git clone <repo> <directory>

Klonuje repozytorium znajdujące się w lokalizacji <repo> do folderu o nazwie ~<directory>! na komputerze lokalnym.

Klonowanie konkretnego tagu

git clone --branch <tag> <repo>

Klonuje repozytorium znajdujące się w lokalizacji <repo> oraz klonuje wyłącznie referencję dla tagu <tag>.

Klonowanie płytkie

git clone -depth=1 <repo>

Klonuje repozytorium znajdujące się w lokalizacji <repo> oraz klonuje wyłącznie historię commitów określoną za pomocą opcji depth=1. W tym przykładzie jest tworzony klon repozytorium <repo>, a w nowo sklonowanym repozytorium uwzględniany jest tylko najnowszy commit. Płytkie klonowanie przydaje się najbardziej podczas pracy z repozytoriami o obszernej historii commitów. Obszerna historia commitów może powodować problemy ze skalowaniem, takie jak ograniczenia ilości miejsca na dysku i długi czas oczekiwania podczas klonowania. Płytkie klonowanie ułatwia wyeliminowanie tego typu problemów ze skalowaniem.

Opcje konfiguracji


git clone -branch

Argument -branch pozwala wskazać konkretną gałąź do klonowania zamiast gałęzi głównej, na którą zazwyczaj wskazuje zdalny wskaźnik HEAD. Ponadto zamiast gałęzi można przekazać tag, aby uzyskać identyczny efekt.

git clone --branch

git clone -mirror i git clone -bare

git clone --bare

Podobnie jak w przypadku polecenia git init --bare po przekazaniu argumentu -bare do polecenia git clone zostanie wykonana kopia zdalnego repozytorium z pominięciem katalogu roboczego. Oznacza to, że repozytorium zostanie skonfigurowane wraz z historią projektu i możliwością wypychania oraz ściągania jego zawartości, jednak bez możliwości jej bezpośredniej edycji. Ponadto w przypadku repozytorium utworzonego z opcją -bare nie zostaną skonfigurowane żadne gałęzie zdalne. Podobnie jak w przypadku polecenia git init --bare to polecenie służy do utworzenia hostowanego repozytorium bez możliwości bezpośredniej edycji przez programistów.

git clone --mirror

Przekazanie argumentu --mirror powoduje przekazanie w sposób niejawny argumentu --bare. Oznacza to, że działanie argumentu --bare jest dziedziczone przez argument --mirror. W efekcie tworzone jest repozytorium początkowe bez edytowalnych plików roboczych. Dodatkowo argument --mirror powoduje sklonowanie wszystkich rozszerzonych referencji repozytorium zdalnego i zachowanie konfiguracji śledzenia gałęzi zdalnej. Następnie można uruchomić za pomocą polecenia git remote aktualizację kopii lustrzanej, co spowoduje zastąpienie wszystkich referencji z pierwotnego repozytorium. W ten sposób uzyskuje się dokładną „kopię lustrzaną” funkcjonalności.

Inne opcje konfiguracji

Kompletną listę pozostałych opcji polecenia „git clone” można znaleźć w oficjalnej dokumentacji systemu Git. W tym dokumencie przyjrzymy się kilku innym typowym opcjom.

git clone --template

git clone --template=<template_directory> <repo location>

Klonuje repozytorium w lokalizacji <repo location> i stosuje szablon z katalogu <template directory> do nowo utworzonej gałęzi lokalnej. Dokładne informacje na temat szablonów Git można znaleźć na stronie git init.

Adresy URL w systemie Git


Git ma własną składnię adresów URL, która jest używana do przekazywania lokalizacji zdalnych repozytoriów do poleceń Git. Polecenie git clone jest najczęściej używane w przypadku zdalnych repozytoriów, dlatego przyjrzymy się teraz składni adresu URL w Git.

Protokoły URL w systemie Git

'- SSH

Secure Shell (SSH) jest powszechnym uwierzytelnionym protokołem sieciowym, który jest domyślnie skonfigurowany na większości serwerów. SSH jest protokołem uwierzytelnionym, dlatego przed nawiązaniem połączenia należy ustalić dane uwierzytelniające z serwerem hostującym. ssh://[user@]host.xz[:port]/path/to/repo.git/

'- GIT

Protokół unikatowy dla systemu Git. Git zawiera demona działającego na porcie (9418). Protokół jest podobny do SSH, jednak NIE UWZGLĘDNIA UWIERZYTELNIANIA. git://host.xz[:port]/path/to/repo.git/

'- HTTP

Protokół przesyłania dokumentów hipertekstowych (Hypertext Transfer Protocol). Jest to protokół sieciowy najczęściej stosowany do przesyłania danych HTML stron internetowych przez Internet. Git można skonfigurować do komunikacji za pośrednictwem protokołu HTTP w następujący sposób: http[s]://host.xz[:port]/path/to/repo.git/

Podsumowanie


W tym dokumencie przyjrzeliśmy się bliżej poleceniu git clone. Najważniejsze wnioski:

1. Polecenie git clone służy do tworzenia kopii repozytorium docelowego.

2. Repozytorium docelowe może być lokalne lub zdalne.

3. Git obsługuje kilka protokołów sieciowych umożliwiających połączenie z repozytoriami zdalnymi.

4. Dostępnych jest wiele różnych opcji konfiguracji, za pomocą których można zmienić zawartość klona.

Szczegółowe informacje na temat funkcji polecenia git clone można znaleźć w oficjalnej dokumentacji systemu Git. Praktyczne przykłady użycia polecenia „git clone” opisano również w naszym przewodniku dotyczącym konfigurowania repozytorium.


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.

Ludzie współpracujący przy ścianie pełnej narzędzi

Blog Bitbucket

Ilustracja DevOps

Ścieżka szkoleniowa DevOps

Demonstracje funkcji z ekspertami Atlassian

Zobacz, jak Bitbucket Cloud współpracuje z Atlassian Open DevOps

Zapisz się do newslettera DevOps

Thank you for signing up