Konfigurowanie repozytorium
W niniejszym samouczku omówimy sposób zakładania repozytorium w systemie kontroli wersji Git. Poprowadzimy Cię przez proces inicjowania repozytorium Git dla nowego lub istniejącego projektu. Poniżej przedstawiamy przykłady repozytoriów utworzonych lokalnie i sklonowanych ze zdalnych. Samouczek zakłada podstawową znajomość interfejsu wiersza poleceń.
Najważniejsze zagadnienia zawarte w tym przewodniku to:
- Inicjowanie nowego repozytorium Git
- Klonowanie istniejącego repozytorium Git
- Zatwierdzanie zmodyfikowanej wersji pliku w repozytorium
- Konfigurowanie repozytorium Git do współpracy zdalnej
- Często używane polecenia systemu kontroli wersji Git
Ukończenie tego modułu zapewni Ci umiejętność tworzenia repozytoriów Git, używania typowych poleceń Git, zatwierdzania zmodyfikowanych plików, przeglądania historii projektu oraz konfigurowania połączenia z serwisem hostingowym Git (Bitbucket).
Czym jest repozytorium Git?
Repozytorium Git to wirtualny magazyn Twojego projektu. Umożliwia zapisywanie wersji kodu, do których możesz wrócić w razie potrzeby.
Inicjowanie nowego repozytorium: git init
Do utworzenia nowego repozytorium używamy polecenia git init. Git init to jednorazowe polecenie, którego używamy podczas wstępnej konfiguracji nowego repozytorium. Wykonanie tego polecenia spowoduje utworzenie nowego podkatalogu .git w bieżącym katalogu roboczym. Spowoduje to również utworzenie nowej gałęzi main.
Wersjonowanie istniejącego projektu za pomocą nowego repozytorium Git
Poniższy przykład jest oparty na założeniu, że dysponujesz już istniejącym folderem projektu, w którym chcesz utworzyć repozytorium. Najpierw przejdź za pomocą cd do głównego folderu projektu, a następnie wykonaj polecenie git init.
materiały pokrewne
Gałąź Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
cd /path/to/your/existing/code
git initSkierowanie git init do istniejącego katalogu z projektem spowoduje wykonanie tej samej wstępnej konfiguracji, co wspomniana powyżej, ale w odniesieniu do tego katalogu projektowego.
git init <project directory>Odwiedź stronę na temat inicjowania repozytorium, aby uzyskać bardziej szczegółowe informacje na temat polecenia git init.
Klonowanie istniejącego repozytorium: git clone
Polecenie git clone to najczęściej stosowana przez użytkowników metoda uzyskania lokalnej 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 odbywa się z poziomu jego lokalnego repozytorium.
git clone <repo url>Polecenie git clone służy do tworzenia kopii (czyli klonów) zdalnych repozytoriów. Do git clone przekazujesz adres URL repozytorium. Git obsługuje kilka różnych protokołów sieciowych i odpowiadających im formatów URL. W tym przykładzie będziemy używać protokołu Git SSH. Adresy URL Git SSH opierają się na szablonie: git@HOSTNAME:USERNAME/REPONAME.git
Przykładowy adres URL Git SSH to: git@bitbucket.org:rhyolight/javascript-data-store.git, gdzie:
HOSTNAME (NAZWA HOSTA): bitbucket.orgUSERNAME (NAZWA UŻYTKOWNIKA): rhyolightREPONAME (NAZWA REPOZYTORIUM): javascript-data-store
Po wykonaniu polecenia najnowsza wersja plików ze zdalnego repozytorium w gałęzi main zostaje ściągnięta i dodana do nowego folderu. Nowy folder otrzymuje nazwę na podstawie REPONAME, w tym przypadku javascript-data-store. Folder ten będzie zawierać pełną historię zdalnego repozytorium oraz nowo utworzonej gałęzi main.
Aby uzyskać więcej informacji na temat stosowania polecenia git clone i obsługiwanych formatów adresów URL, odwiedź stronę na temat polecenia git clone.
Zapisywanie zmian w repozytorium: git add i git commit
Teraz, gdy repozytorium zostało sklonowane lub zainicjowane, możesz w nim zatwierdzić zmiany w wersjach plików. W poniższym przykładzie zakładamy, że projekt został utworzony pod adresem /path/to/project. Wykonywane są następujące czynności:
- Zmiana katalogu na
/path/to/project - Utworzenie nowego pliku
CommitTest.txtz zawartością ~"test content for git tutorial"~ - Dodanie pliku
CommitTest.txtdo przechowalni repozytorium za pomocą polecenia git add - Utworzenie nowego commitu z komunikatem opisującym zatwierdzany zakres pracy
cd /path/to/project
echo "test content for git tutorial" >> CommitTest.txt
git add CommitTest.txt
git commit -m "added CommitTest.txt to the repo"Po wykonaniu tego przykładu plik CommitTest.txt zostanie dodany do historii Twojego repozytorium i przyszłe aktualizacje tego pliku będą śledzone.
W tym przykładzie wprowadziliśmy dwa dodatkowe polecenia git: add i commit. To był dość ograniczony przykład, ale oba polecenia są dokładniej omówione na stronach dotyczących git add i git commit. Innym częstym przypadkiem użycia git add jest opcja --all. Wykonanie polecenia git add --all spowoduje pobranie wszystkich zmienionych i nieśledzonych plików i dodanie ich do repozytorium oraz aktualizację drzewa roboczego repozytorium.
Współpraca między repozytoriami: git push
Trzeba zrozumieć, że koncepcja „kopii roboczej” w systemie Git różni się znacznie od kopii roboczej otrzymywanej poprzez wyewidencjonowanie kodu źródłowego z repozytorium SVN. W przeciwieństwie do SVN w systemie Git nie ma rozróżnienia na kopie robocze i centralne repozytorium — wszystkie one są pełnoprawnymi repozytoriami Git.
To sprawia, że współpraca w Git zasadniczo różni się od tej 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.
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”. Uzyskuje się to poprzez zastosowanie pewnej konwencji, a nie wymusza za pomocą integralnej cechy samego systemu kontroli wersji.
Repozytoria początkowe a sklonowane
Jeżeli do utworzenia lokalnego repozytorium w poprzedniej części „Inicjowanie nowego repozytorium” zostało użyte polecenie git clone, Twoje repozytorium jest już skonfigurowane do współpracy zdalnej. Polecenie git clone automatycznie konfiguruje repozytorium ze zdalnym wskazaniem na adres URL Git, na podstawie którego zostało sklonowane. Oznacza to, że gdy wprowadzisz zmiany w pliku i je zatwierdzisz, możesz je wypchnąć za pomocą git push do zdalnego repozytorium.
Z kolei w przypadku użycia git init do utworzenia zupełnie nowego repozytorium nie będziesz dysponować zdalnym repozytorium do wypchnięcia zmian. Częstym zwyczajem jest tworzenie nowego repozytorium w hostowanym serwisie Git, takim jak Bitbucket. Serwis ten poda adres URL Git, który będzie można następnie dodać do lokalnego repozytorium Git i używać na potrzeby polecenia git push. Po utworzeniu zdalnego repozytorium w wybranym serwisie należy zaktualizować swoje lokalne repozytorium za pomocą mapowania. Proces ten omawiamy poniżej w przewodniku konfiguracji.
Jeśli wolisz hostować własne repozytorium zdalne, musisz skonfigurować puste repozytorium początkowe. Oba polecenia, git init oraz git clone, dopuszczają argument --bare. Najczęstszym zastosowaniem repozytorium początkowego jest stworzenie zdalnego centralnego repozytorium Git.
Konfiguracja: git config
Gdy zdalne repozytorium już zostanie skonfigurowane, należy dodać adres URL zdalnego repozytorium do swojego lokalnego git config oraz ustawić gałąź nadrzędną (upstream) dla gałęzi lokalnych. Taką możliwość oferuje polecenie git remote.
git remote add <remote_name> <remote_repo_url>To polecenie zmapuje zdalne repozytorium pod adresem
git push -u <remote_name> <local_branch_name>Polecenie to wypycha gałąź lokalnego repozytorium oznaczone jako < local_branch_name > do zdalnego repozytorium < remote_name >.
Więcej informacji o git remote znajdziesz na stronie dotyczącej tego polecenia.
Oprócz adresu zdalnego repozytorium możesz także ustawić globalne opcje konfiguracyjne Git, takie jak nazwa użytkownika czy e-mail. Polecenie git config umożliwia skonfigurowanie instalacji Git (lub pojedynczego repozytorium) z poziomu wiersza poleceń. Pozwala ono zdefiniować wszystko, od informacji o użytkowniku, przez preferencje, po zachowanie repozytorium. Poniżej przedstawiamy kilka popularnych opcji konfiguracyjnych.
Git przechowuje opcje konfiguracyjne w trzech osobnych plikach, co pozwala określić ich zakres dla poszczególnych repozytoriów (local), użytkowników (global) lub całego systemu (system):
- Local:
/.git/config - Global:
/.gitconfig— ustawienia dotyczące użytkowników. W tym miejscu przechowywane są opcje ustawione z flagą --global. - System:
$(prefix)/etc/gitconfig— ustawienia systemowe.
Wskaż nazwę autora, która będzie stosowana dla wszystkich commitów w bieżącym repozytorium. Zazwyczaj do ustawienia opcji konfiguracyjnych dla bieżącego użytkownika używa się flagi --global.
git config --global user.name <name>Określa nazwę autora, która będzie stosowana dla wszystkich commitów autorstwa bieżącego użytkownika.
Dodanie opcji --local lub nieprzekazanie opcji poziomu konfiguracji spowoduje ustawienie user.name dla bieżącego lokalnego repozytorium.
git config --local user.email <email>Określa e-mail autora, który będzie stosowany dla wszystkich commitów autorstwa bieżącego użytkownika.
git config --global alias.<alias-name> <git-command>Tworzy skrót dla polecenia Git. Jest to zaawansowane narzędzie do tworzenia własnych skrótów do często używanych poleceń Git. Prosty przykład będzie wyglądać następująco:
git config --global alias.ci commitPowoduje to utworzenie polecenia ci pełniącego funkcję skrótu dla git commit. Aby dowiedzieć się więcej o aliasach git, odwiedź stronę polecenia git config.
it config --system core.editor <editor>Określa edytor tekstu używany przez polecenia typu git commit dla wszystkich użytkowników na bieżącym urządzeniu. Argument < editor > powinien być poleceniem uruchamiającym żądany edytor (np. vi). W tym przykładzie wprowadzamy opcję --system. Opcja --system ustawi konfigurację dla całego systemu, czyli wszystkich użytkowników i repozytoriów na danym urządzeniu. Więcej szczegółowych informacji o poziomach konfiguracji można znaleźć na stronie polecenia git config.
git config --global --editOtwiera globalny plik konfiguracyjny w edytorze tekstu celem ręcznej edycji. Szczegółowy przewodnik, jak skonfigurować edytor tekstu dla systemu Git, można znaleźć na stronie polecenia git config.
Dyskusja
Wszystkie opcje konfiguracyjne są przechowywane w plikach ze zwykłym tekstem, więc polecenie git config jest po prostu wygodnym interfejsem wiersza poleceń. Zazwyczaj wystarczy skonfigurować instalację Git tylko przy pierwszym rozpoczęciu pracy na nowym urządzeniu i praktycznie we wszystkich przypadkach warto użyć flagi --global. Jednym z istotnych wyjątków jest nadpisywanie adresu e-mail autora. Możesz chcieć ustawić swój osobisty adres e-mail dla repozytoriów osobistych i open source, a służbowy dla repozytoriów związanych z pracą.
Git przechowuje opcje konfiguracyjne w trzech osobnych plikach, co pozwala określić ich zakres dla poszczególnych repozytoriów, użytkowników lub całego systemu:
/.git/config ~/.gitconfig— ustawienia dotyczące użytkowników. W tym miejscu przechowywane są opcje ustawione z flagą --global.$(prefix)/etc/gitconfig— ustawienia systemowe.
W przypadku zaistnienia konfliktu między opcjami zawartymi w tych plikach, ustawienia lokalne mają pierwszeństwo przed ustawieniami użytkownika; te zaś — przed ogólnosystemowymi. Po otwarciu dowolnego z tych plików zobaczysz coś mniej więcej takiego:
[user] name = John Smith email = john@example.com [alias] st = status co = checkout br = branch up = rebase ci = commit [core] editor = vimMożesz edytować te wartości ręcznie, co da dokładnie taki sam efekt jak użycie polecenia git config.
Przykład
Pierwszą rzeczą, jaką warto zrobić po zainstalowaniu systemu Git, jest podanie swojej nazwy użytkownika i adresu e-mail oraz dostosowanie niektórych ustawień domyślnych. Typowa konfiguracja początkowa będzie wyglądać mniej więcej tak:
Wskaż, kim jest osoba korzystająca z git config
git --global user.name "John Smith" git config --global user.email john@example.comWskaż ulubiony edytor tekstu
git config --global core.editor vimDodaj kilka aliasów w stylu SVN
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.up rebase
git config --global alias.ci commitW ten sposób powstanie plik ~ /.gitconfig z poprzedniej sekcji. Więcej informacji na ten temat znajdziesz na stronie polecenia git config.
Podsumowanie
Pokazaliśmy tu, jak utworzyć repozytorium Git przy użyciu dwóch metod: git init i git clone. Przewodnik ten można zastosować do zarządzania kodem źródłowym oprogramowania lub inną treścią, która wymaga wersjonowania. Zaprezentowaliśmy też polecenia git add, git commit, git push i git remote oraz ogólne zasady ich działania.
Przeczytaj nasz przewodnik umożliwiający wybór odpowiedniego systemu repozytorium kodu dla zespołu!
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
