Pierwsze kroki z Git

Instalacja

Zdecydowana większość systemów i narzędzi do automatyzacji bazuje na takich czy innych plikach tekstowych. Bez względu na to, czy będziemy automatyzowali za pomocą Ansible, skryptów w Pythonie czy komercyjnych systemów, takich jak UCS Director czy VMware vRealize, zawsze będzie do napisania kawałek kodu. Zatem, warto go w jakiś sposób śledzić. Dlatego, pierwszym narzędziem, od którego zaczniemy naszą przygodę z automatyzacją jest Git. Służy on właśnie do śledzenia zmian w kodzie źródłowym czyli do tak zwanego wersjonowania. Git jest darmowy i jest dostępny dla systemów Linux, Mac oraz Windows. Ponieważ ten ostatni używany jest przez administratorów sieciowych najczęściej (tak wynika z moich obserwacji, ale mogę się mylić), to na nim skupimy się na początku.

Git dostępny jest na stronie https://git-scm.com. Należy go stamtąd ściągnąć (wersję 32bit lub 64bit) i zainstalować na lokalnym komputerze. Choć instalacja jest bardzo prosta (klikanie w Next) to na jedną rzecz należy zwrócić uwagę. Jednym z kroków w procesie wersjonowania jest dodawanie krótkiego komentarza, bazującego na wzorcu. Do ich tworzenia Git domyślnie wykorzystuje edytor vim. Jest on bardzo specyficzny i nieintuicyjny przy pierwszym kontakcie. Dlatego, w trakcie instalacji należy wybrać bardziej przyjazny edytor. Dostępne są między innymi Nano, Notapd++ czy Sublime Text. Pozostałe opcje instalacji możemy zostawić domyślne.

Jeżeli nie manipulowaliśmy nic przy domyślnych ustawieniach to katalog z plikiem wykonywalnym Git zostanie dodany do zmiennej systemowej PATH, zatem polecenie git będzie dostępne w dowolnym miejscu. Dostępna jest też dedykowana powłoka git-bash (dostępna z menu Start). Zachęcam do jej używania, ponieważ pokazuje ona status danego repozytorium w bardziej przejrzysty sposób (kolorystyka, komunikaty).

Wygląd konsoli Git-bash

Konfiguracja

Git jest systemem rozproszonym (więcej na temat mechaniki jego działania w kolejnym artykule). Na początku będziemy z niego korzystali lokalnie, ale później będziemy dzielili się kodem z innymi administratorami. Dlatego, zanim zaczniemy korzystać z Gita należy się „przedstawić”. Służą do tego dwa polecenia (oba są wymagane):

git config --global user.name "Krzysztof Zaleski"
git config --global user.email "kontakt@nowoczesnysieciowiec.pl"

Dane te załączane są do każdego kodu „wysyłanego” do centralnego repozytorium na serwerze Git. Chodzi o identyfikowanie właściciela zmian (nie, nie o szukanie winnego :-))

Konfiguracja użytkownika przechowywana jest domyślnie w katalogu domowym, w pliku .gitconfig. Konfiguracja globalna znajduje się w pliku c:\Program Files\Git\mingw64\etc\gitconfig (jeżeli nie zmienialiśmy ścieżki instalacji). Dane te możemy edytować ręcznie lub poleceniem git config. Listę wszystkich ustawień możemy wyświetlić za pomocą:

$ git config --list
[...]
core.editor="C:\Program Files\Sublime Text 3\subl.exe" -w
user.name=Krzysztof Zaleski
user.email=kontakt@nowoczesnysieciowiec.pl
[...]

Jak widać, jest tam też informacja o wspomnianym wcześniej edytorze (linia 3). Jeżeli przez przypadek ominęliśmy ten etap przy instalacji, to zawsze można zmienić ustawienia w pliku globalnym.

Pierwszy projekt

Git gotowy jest do pracy. Stwórzmy sobie przykładowy projekt, w pustym katalogu git-101. Wersjonowanie inicjujemy poleceniem git init, wykonywanym wewnątrz utworzonego katalogu. Katalog może być pusty lub zawierać pliki źródłowe. Polecenie to nie zmienia nic w samych plikach, inicjuje tylko strukturę katalogu roboczego .git.

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101
$ git init
Initialized empty Git repository in C:/Users/devops/Documents/NetDevOps/git-101/.git/
devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master) 

Nowo utworzony, ukryty katalog .git (linia 3) – w systemach linuksowych pliki i katalogi poprzedzone kropką traktowane jako ukryte – będzie zawierał wszystkie informacje na temat zmian w repozytorium. Jak widzimy (linia 4), zmienił się też status repozytorium na master. Master to nasz główny kod. O innych strukturach, takich jak Branch, opowiem w kolejnych artykułach.

Stwórzmy sobie teraz przykładowy plik z konfiguracją, np. snmp.conf o zawartości:

snmp-server community public ro

Zobaczmy, co nam pokaże status repozytorium (często zwanym w skrócie repo), wyświetlany poleceniem git status:

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git status
 On branch master
 No commits yet
 Untracked files:
   (use "git add …" to include in what will be committed)
      snmp.conf
 nothing added to commit but untracked files present (use "git add" to track)

Git wykrył, że mamy nowy plik, ale nie dodaliśmy go jeszcze do repozytorium (Untracked files – linia 5), więc nie podlega on wersjonowaniu. Plik dodajemy do śledzenia wskazując go poleceniem „git add snmp.conf„.

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git add snmp.conf

Jeżeli wszystkie pliki w katalogu będziemy wersjonowali, możemy użyć polecenia „git add .„, które obejmie cały lokalny katalog, wraz z jego podkatalogami. Jak teraz wygląda status?

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git status
 On branch master
 No commits yet
 Changes to be committed:
   (use "git rm --cached …" to unstage)
         new file: snmp.conf

Jak widać, plik snmp.conf jest teraz już śledzony, ale nie zatwierdzony (linia 5). Zmiany zatwierdzamy poleceniem git commit. Zatwierdzenie takie spowoduje, że aktualna wersja pliku zostanie zarchiwizowana w katalogu .git. W ten sposób budujemy historię zmian. Commit powinniśmy wykonać po każdej kluczowej zmianie (to jest też nasz backup). Zatwierdzać możemy pojedyncze pliki lub tak jak poprzednio, cały katalog, za pomocą zmiennej -a. Git zarchiwizuje tylko te pliki, które uległy zmianie. Do każdego zatwierdzenia musimy dodać komentarz, opisujący w skrócie jakich dokonaliśmy zmian. Całość polecenia wygląda tak:

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git commit -a -m "Utworzenie pliku"
 [master (root-commit) 8867904] Utworzenie pliku
  1 file changed, 1 insertion(+)
  create mode 100644 snmp.conf

Każda zmiana (commit) otrzymuje swój unikalny numer (linia 3). Jest on wykorzystywany do przywracania danej wersji repo. Sam identyfikator jest bardzo długi, ale już pierwszych kilka cyfr wystarczy do unikalnej identyfikacji.

Zmieńmy teraz zawartość pliku snmp.conf, wstawiając secret zamiast public„.

snmp-server community private ro

Jak zmienił się status?

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git status
 On branch master
 Changes not staged for commit:
   (use "git add …" to update what will be committed)
   (use "git checkout -- …" to discard changes in working directory)
          modified: snmp.conf 

Git automatycznie wykrył zmianę w pliku (linia 4). Zatwierdzamy ją tak jak poprzednio, dodając odpowiedni komentarz.

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git commit -a -m "Zmiana community"
 [master 515a0d3] Zmiana community
  1 file changed, 1 insertion(+), 1 deletion(-)

Aby obejrzeć sobie historię zmian, wykonujemy polecenie git log. Ma ono wiele pożytecznych parametrów, dzięki którym możemy wpływać na sposób i zakres wyświetlanych informacji (więcej przykładów w kolejnych artykułach).

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git log --pretty=oneline
 515a0d35e0915a8e3bc384f79e58ecff199a70d8 (HEAD -> master) Zmiana community
 8867904e32d4eb4bd9da616b222117eb9c40945b Utworzenie pliku

devops@lab-vm MINGW64 ~/Documents/NetDevOps/git-101 (master)
$ git log --pretty=format:"%h - %an, %ar : %s"
 515a0d3 - Krzysztof Zaleski, 5 minutes ago : Zmiana community
 8867904 - Krzysztof Zaleski, 10 minutes ago : Utworzenie pliku

Podsumowanie

Tym samym przeszliśmy przez prosty proces tworzenia repozytorium, dodawania do niego pliku i zatwierdzania zmian. Podsumowując, mamy póki co polecenia:

git init                     - zainicjowanie repo
git status                   - wyświetlenie statusu
git add .                    - dodanie katalogu do śledzenia
git commit -a -m "Komentarz" - zatwierdzenie zmian
git log                      - wyświetlenie historii

Zapraszam na kolejną część, w której dowiemy się jak przywracać zmiany, jak tworzyć odnogę konfiguracji, tak zwany Branch i jak go później łączyć z głównym kodem.

1 komentarz do wpisu “Pierwsze kroki z Git”

Dodaj komentarz

ten − eight =