Kontrola wersji z Git cz. 2 – instalacja, konfiguracja i pierwszy commit
|W tym wpisie zainstalujemy a następnie skonfigurujemy Git do poprawnej pracy. Utworzymy także pierwsze repozytorium i dokonamy pierwszego zatwierdzenia zmian.
Instalacja
Windows
Pobieramy instalator z tej strony. W czasie instalacji, przy kroku „Adjusting you PATH environment„, wybieramy opcję „Use Git from the Windows Prompt„. Pozwoli ona używać komend Git’a z normalnego wiersza poleceń (np. cmd.exe). Po instalacji dostępna będzie także powłoka Git’a: Git Bash.
W pozostałych krokach zostawiamy domyślne opcje.
Linux
W przypadku Linuxowych systemów najlepiej będzie skorzystać z domyślnego dla danej dystrybucji programu do zarządzania pakietami. Dla Ubuntu będzie to przykładowo apt-get:
apt-get install git
Mac
Dla komputerów typu Mac możemy skorzystać z graficznego instalatora dostępnego tutaj. Inny sposób to instalacja Homebrew (o ile go już nie masz). W tym celu wpisz w terminalu:
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
Teraz możesz łatwo doinstalowywać dodatkowe pakiety. W celu instalacji Git’a wystarczy wpisać:
brew install git
Po udanej instalacji, w celu sprawdzenia czy wszystko działa prawidłowo, możemy wpisać w konsoli/wierszu poleceń następujące polecenie:
git --version
Jeżeli wyświetli się nam odpowiedź w stylu:
git version 1.9.4.msysgit.0
to wszystko przebiegło prawidłowo i możemy przejść do następnego kroku.
Konfiguracja
Zaraz po instalacji musimy skonfigurować Git’a aby wszystkie dokonane zmiany były oznaczane naszym imieniem i nazwiskiem (bądź nikiem – jak kto woli) oraz adresem e-mail. W tym celu musimy odpalić dwa polecenia:
git config --global user.name "Imię Nazwisko / Nick" git config --global user.email mojmail@gmail.com
Jak łatwo się domyślić pierwszą linią ustawiamy naszą tożsamość a drugą adres e-mail. Dla pewności można wyświetlić zapisane opcje poleceniem:
git config --list
Czasem może się zdarzyć sytuacja w której pewne zmienne konfiguracyjne będą się powtarzać. Jest to spowodowane faktem że Git odczytuje je najpierw z ścieżek systemowych a następnie z lokalnego repozytorium (jeżeli istnieje). Proponuję wywołać polecenie „git config –list” najpierw w pustym katalogu a następnie w istniejącym repozytorium. Zachęcam do eksperymentowania. W celu wyświetlenia rzeczywistej wartości zmiennej (w przypadku gdy wyświetli nam się więcej niż raz) możemy użyć polecenia „git config nazwa_zmiennej”:
git config user.name
Pierwsze repozytorium
W celu rozpoczęcia śledzenia zmian musimy utworzyć nowe repozytorium lub sklonować istniejące. Na razie zajmiemy się tą pierwszą opcją. Aby utworzyć nowe repozytorium w wybranym folderze musimy uruchomić polecenie:
git init
Zostaniemy poinformowani o pomyślnym utworzeniu nowego repozytorium. W celu sprawdzenia aktualnego stanu naszego repozytorium używamy polecenia „git status„. Będzie to jedno z częściej używanych poleceń, więc szybko wejdzie ci w nawyk. Wywołajmy teraz polecenie „git status” na nowo utworzonym repozytorium:
git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track)
Jak widać świeżo utworzone repozytorium jest puste. Zauważmy że Git od razu proponuje nam dodanie nowych plików 🙂 Dodajmy teraz dowolny plik i ponownie odpalmy polecenie „git status„:
git status On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track)
W wyniku wywołania polecenia zostajemy poinformowanie że istnieje nowy plik „README.md”, który nie jest śledzony (jego zmiany nie będą wersjonowane). Aby dodać nasz plik do kontroli wersji skorzystamy z polecenia „git add„, a następnie ponownie sprawdzimy stan przy pomocy „git status„:
git add README.md git status
Tym razem otrzymamy:
On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: README.md
Git informuje nas że plik „README.md” jest przygotowany do wykonania operacji zatwierdzenia zmian (commit). Oznacza to że w chwili obecnej znajduje się on w poczekalni i przy najbliższym zatwierdzeniu zostanie dodany do kontroli wersji. Samą poczekalnią zajmiemy się w osobnym wpisie. Na chwilę obecną wystarczy wiedzieć o tym, że plik w poczekalni również jest śledzony (lokalnie) ale nie został jeszcze zatwierdzony.
Zatwierdzanie zmian
W chwili gdy w poczekalni znajdują się już pliki możemy przejść do zatwierdzenia zmian. Najprościej wykonujemy je przy pomocy polecenia „git commit” z parametrem -m, który pozwala od razu podać krótki komentarza:
git commit -m "Dodanie pliku pomocy"
W odpowiedzi otrzymamy:
[master (root-commit) 6020d2e] Dodanie pliku pomocy 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md
W ten sposób nasze zmiany zostały zatwierdzone a plik dodany do kontroli wersji. Pamiętajmy że zmiany zostały na razie zapisane tylko na lokalnej maszynie w lokalnym repozytorium. Wypychaniem zmian na serwer zajmiemy się w osobnym wpisie.
Zatwierdzanie bez poczekalni
Istnieje sposób zatwierdzania zmian bez dodawania plików za każdym razem do poczekalni. Wystarczy wywołać polecenie „git commit” z parametrem -a. Niestety w ten sposób możemy zatwierdzić zmiany tylko w plikach już śledzonych. Natomiast pliki nowo dodane, które jeszcze nie znajdują się pod kontrolą wersji, musimy dodać przez polecenie „git add„.
git commit -a -m "Opis zmian"
W celu dodaniach wszystkich nowych plików (oraz tych zmodyfikowanych) możemy skorzystać jeszcze z polecenia „git add” dodając znak „.” na końcu. W ten sposób dodamy wszystkie nowe pliki (oraz te zmodyfikowane) do poczekalni:
git add .
Po takim poleceniu pozostaje nam już tylko zatwierdzenie zmian z stosownym komentarzem.
Na chwilę obecną to wszystko. Chciałem skupić się w tym wpisie na samej instalacji i konfiguracji, ale w trakcie pisania stwierdziłem, że pokaże jeszcze na szybko jak wykonać pierwszego commit’a. W następnym wpisie skupię się szczegółowo na całym cyklu życia plików poddawanych kontroli wersji.
Na koniec przyszła mi do głowy jeszcze jedna myśl: czy dodatkowo chciałbyś mieć możliwość obejrzenia powyższego wpisu w formie screencastu ? Jeżeli tak, to daj mi znać w komentarzu. Inne uwagi/komentarze również są mile widziane.