Poniżej dla przypomnienia kilka komend potrzebnych do działania w systemie kontroli wersji Git.
Plik .gitignore
Plik o nazwie .gitignore zawiera informacje o plikach i katalogach, które powinny być pomijane przez system Git. Pliki te nie będą podlegały kontroli wersji. Przykład takiego pliku dla programów w języku Java można znaleźć pod adresem https://github.com/github/gitignore/blob/master/Java.gitignore
Konfiguracja nazwy i adresu e-mail
Aby zatwierdzać zmiany w systemie Git konieczne jest skonfigurowanie wcześniej nazwy użytkownika oraz jego adresu e-mail. Po ich skonfigurowaniu każdy commit, czyli każde zatwierdzenie plików w systemie kontroli wersji opatrzone zostanie tymi informacjami.
Poniżej przykład, jak skonfigurować nazwę i adres-email użytkownika:
1 | git config --global user.name "Jan Kowalski" |
Dodawanie plików
Aby dodać wszystkie nowe pliki do kontroli wersji, używamy komendy:
1 | git add . |
Uwaga: po komendzie git add występuje znak kropki
Zatwierdzanie zmian
Aby zatwierdzić zmiany (czyli dodanie nowych plików, zmianę istniejących lub usunięcie plików), używamy komendy:
1 | git commit -am "Komentarz" |
Po przełączniku -am wpisujemy krótki komentarz opisujący zmiany. Warto, by czytając ten komentarz było wiadomo, czego dotyczyła zmiana lub co się zmieniło. Można tu wpisać np. informację, jaki błąd został poprawiony, co nowego zostało dodane itp.
Pobieranie zmian z serwera
Aby pobrać najnowsze zmiany ze zdlanego repozytorium (np. z GitHub-a), używamy komendy:
1 | git pull origin master |
Komanda ta zakłada, że zmiany pobieramy z gałęzi master. “master“ to podstawowa gałąź w repozytorium Git. Do czasu aż nie będziemy zajmowali się tworzeniem innych gałęzi, to będzie nasza podstawowa i jedyna gałąź, na której będziemy pracować w systemie Git. Dlatego często komendy będą zawierały nazwę tej właśnie gałęzi.
Czasem próba pobrania zmian nie powiedzie się. Będzie tak na przykład wtedy, kiedy ktoś inny zatwierdzi zmiany, których my jeszcze na swoim komputerze nie mamy. Albo wtedy, kiedy lokalnie zmienimy zawartość plików, ale zmiany te nie zostały przesłane jeszcze do systemu kontroli wersji.
Warto wtedy użyć komendy git pull ze spacjalnym przełącznikiem –rebase:
1 | git pull --rebase origin master |
Wysyłanie zmian na serwer
Po zatwierdzeniu zmian komendą git commit trzeba jeszcze pamiętać o wysłaniu tych zmian na serwer (np. GitHub). Robimy to komendą:
1 | git push origin master |
Status repozytorium
Jedną z najprzydatniejszych i najczęściej używanych komend jest:
1 | git status |
Komenda ta pozwala zorientować się, w jakim stanie jest nasz magazyn plików. Czy jakieś pliki zostały zmienione lub usunięte, czy są jakieś pliki w katalogu, ale nie są jeszcze do magazynu dodane, więc nie podlegają kontroli wersji itd.
Klonowanie repozytorium
Na koniec może przydać się jeszcze jedna komenda. Zwłaszcza, jeśli to nie my będziemy autorem repozytorium, a od kogoś innego dostaniemy adres repozytorium Git po to, by pobrać jego zawartość na swój komputer.
Na przykład pod adresem https://github.com/Fincon/mongeez-maven-plugin znaleźć można stronę jednego z repozytoriów firmy Fincon. Repozytorium to umieszczone jest w serwisie GitHub.
Po kliknięciu klawisza Clone or download możemy zobaczyć jaki jest adres tego repozytorium. Adres to git@github.com:Fincon/mongeez-maven-plugin.git
Aby go pobrać używamy komendy:
1 | git clone git@github.com:Fincon/mongeez-maven-plugin.git |
Domyślnie po sklonowaniu repozytorium na dysku utworzony zostanie katalog o nazwie takiej, jak nazwa repo, czyli w powyższym przykładzie będzie to katalog mongeez-maven-plugin.
PermaLink: https://java.kozlowski.photos/2017/05/git/