Systemy kontroli wersji od podszewki, czyli jak szybko postawić i skonfigurować repozytoria Git lub SVN …

O tym, jak używając tylko klawiatury, odrobiny chęci, wiedzy oraz protokołu SSH, stworzyć w pełni działające repo dla wielu użytkowników.

Coś dla adminów śledzących przypadki z życia wzięte z serii #AdminCases bo dosłownie w artykule jest zawarte how to do it, jak i trochę dla dev-ów, bo i polecenia repozytoriów Git i SVN będą się pałętać, a to wszystko w wersji dla ascetów – klikaniu mówimy stanowcze: dziękuję, nie dzisiaj :)

Nie wiem, czy uważacie tak ja, że podstawy są istotne i ważne – również w branży, gdzie na dnie wszystkich zaklęć znajdują się zera i jedynki. Niejednokrotnie rzuciło mi się w oczy u naszych zuchów w wieku chuligańskim, wchodzących prężnie w świat informatyki, że ze względu na różne udogodnienia, które powodują, że rozwiązania podawane są na tacy (głównie przez klikanie), następuje podwyższenie poziomu abstrakcji kosztem podstaw. To właśnie Oni uważają, że właściwie GitHub, GitLab i Git to to samo lub też naparzają commity czy inne funkcje (choćby w Visual Studio Code), a nie zawsze są świadomi tego co zachodzi po drugiej stronie. Tego, że wykonywanych jest tam szereg poleceń, aby wszystko pięknie się wyświetlało i żeby mieć na ręku różnice pomiędzy wersjami, czy inne świetne udogodnienia – i mówię to bez przekąsu, bo rzeczywiście są przydatne.

Nasza koleżanka Agnieszka Piętka popełniła artykuły na temat: Git: 5 przykładów, które ułatwią Ci życie (na chwilę obecną dostępne 2 – część pierwsza oraz część druga) i wielka chwała jej za to, bo właśnie pokazuje zaklęcia, które powinno się znać działając w repozytorium Git i mam nadzieję, że jeszcze ich trochę spreparuje. Postaram się nie wchodzić jej w paradę, ponieważ ja raczej będę patrzył przez pryzmat tego, który kreuje repozytoria, aby tworzący programy miał, gdzie oddawać wytwory swojej ciężkiej (lub też nie, ale jednak ;) ) pracy.

Przede wszystkim – jak to zwykle u mnie bywa – musimy założyć pewne ramy, których będę się trzymał i będzie zawarte w tym, co wyjdzie spod moich palców:

• będę pisał o dwóch repozytoriach Git i SVN – nie o pochodnych (oczywiście wspomniane będą, ale tylko jako przykład technologii)
• ograniczę się do tworzenia dostępów via SSH dla obu repozytoriów więc inne formy połączeń w tym artykule najnormalniej w świecie nie wystąpią
• po utworzeniu repozytoriów pokażę tylko podstawowe polecenia, aby móc je zasilić i sprawdzić, co z czym się je

No to jak to mówią: komu Let’s temu Go :)

Zacznijmy od zupełnej podstawy dla kompletnych lajkoników (laików brzmi tak niemiło, a przecież nie chcemy sprawiać przykrości). Czym jest repozytorium kodu i trzymający nad nim pieczę system kontroli wersji:

Repozytorium kodu – mówiąc potocznie – to magazyn, gdzie kody źródłowe są przechowywane. System kontroli wersji (ang. version/revision control system) – oprogramowanie służące do śledzenia zmian głównie w kodzie źródłowym oraz pomocy programistom w łączeniu zmian dokonanych w plikach przez wiele osób w różnym czasie. Wikipedia

Jasne prawda? Teraz jeszcze tylko, aby wszystko usystematyzować dorzucę kilka typów repozytoriów, jeżeli chodzi o architekturę:

• lokalne – czyli jest to rozwiązanie ograniczające się do jednego komputera, chociaż jeżeli będzie to zasób w postaci NFS może być, po części, wykorzystywany na wielu (np. SCCS i jego brat w świecie Gnu CSSC, czyli Compatibly Stupid Source Control)
• scentralizowane – czyli serwer pełniący rolę bazy centralnej, gdzie trafiają wszystkie zmiany na zasadzie klient-serwer (np. SVN)
• rozproszone – czyli mówiąc kolokwialnie każdy użytkownik posiada klon repozytorium, z którym wszyscy użytkownicy się synchronizują i prowadzą niezależne gałęzie oprogramowania a na koniec można to wszystko zmerge’ować. Przedstawicielem tego typu repozytorium jest Git

No to teraz może, czym się charakteryzują repozytoria kodu i w jakim celu się je stosuje ergo w czym nam pomagają. Najważniejsze zalety repozytorium to:

• śledzenie historii zmian pojawiających się w plikach
• wgląd do wcześniej wprowadzonych zmian i możliwość sprawdzenia, co, kiedy i przez kogo zostało zmienione
• możliwość cofania zmian
• możemy tworzyć tak zwane boki czy też gałęzie (branch) np. tworząc nową funkcjonalność
• ułatwienie tworzenia pakietu oprogramowania innymi słowy wersji aplikacji
• możliwość wykonania kopii zapasowej na przykład poprzez klonowanie
• umożliwia pracę w zespole

Co by tu jeszcze z teorii, żeby nikogo nie zanudzić, a uświadomić nieuświadomionych?

• Commit – zaakceptowanie zmian w repozytorium dokonanych w kodzie
• Branch – odgałęzienie od głównej ścieżki kodu, pozwalające na prace nad jednym kodem wielu osobom, po których zakończeniu możemy scalić
• Checkout – proces w przypadku git to przełączenie się na inne odgałęzienie kodu, a jeżeli chodzi o SVN to przejście to utworzenie kopii roboczej repozytorium
• Clone – dotyczy git i wprost oznacza utworzenie kopii całego repozytorium

No dobrze, reszta powinna wyjść w praniu w trakcie przedstawiania tego, w jaki sposób szybko postawić Git czy SVN, stworzyć repozytorium, wrzucić dane, no i wykonać podstawowe rzeczy – chociażby te wymienione powyżej – i otrzymać wynik w postaci informacji, że jesteśmy super, bo nasz kod źródłowy znajduje się już w repozytorium i możemy napawać się informacjami, co i kiedy zostało zmienione oraz kto tego dokonał.

Zatem ruszajmy w tę podróż.

Dla braci i sióstr będącymi na bakier z systemem operacyjnym Linux – jak nie jesteś root‘em użyj sudo przed poleceniem i miej nadzieję, że jesteś dopisany do sudoers, a jeżeli nie, to udaj się do jakiegoś guru czytaj administratora serwera, żeby Ciebie dodał z uprawnieniami do wykorzystanych w artykule poleceń (albo wykonał je za Ciebie).

SVN, czyli subversion

1. Instalacja

Instalujemy SVN za pomocą menedżera pakietów dedykowanego dla danego systemu operacyjnego (skupiam się na dwóch najpopularniejszy rodzinach):

• rodzina RedHat: yum lub dnf

  yum install subversion dnf install subversion 

• apt install subversion

  apt install subversion

Udało się? To świetnie, a jeżeli nie to trzeba popatrzeć, dlaczego, może system chce powiedzieć: Tej persony nie obsługujemy. Zły system :) Zakładam jednak, że Wasz jednak o ile nie lubi to przynajmniej toleruje, dlatego już macie Subversion zainstalowane i możemy przejść dalej.

2. Konfiguracja

Co zrobimy w pierwszej kolejności? Założymy grupę oraz użytkownika w celach administracyjnych

Grupa svn oraz użytkownik svn:

groupadd svn

useradd -g svn -s /bin/bash -c "User SVN" -m svn 

Przejdźmy teraz do clue tematu, czyli stworzenia repozytorium. Możemy to zrobić od razu we właściwej lokalizacji lub też lokalnie a następnie przeniesiemy drzewo katalogów. Zrobimy to wszystko krok po kroku wtedy nie będzie trzeba sobie zawracać głowy rzeczami niepotrzebnymi co spowoduje, że tylko ważne będą nas nurtować (jakby to było wykonalne).

Wybierzmy teraz miejsce, gdzie ma znajdować się repozytorium i utwórzmy tam katalog –najlepiej na uprawnieniach chwilę wcześniej założonego użytkownika. Należy pamiętać, że taka lokalizacja powinna mieć takie uprawnienia, aby również grupa mogła się tam dostać i coś wykonać. Następnie utworzymy tam nasze repozytorium.

Do dzieła ;)

Dla tych, którzy stwierdzili, że nie warto czytać dokumentacji, skoro jest manual step by step: do utworzenia repozytorium służy polecenie svnadmin, a jeżeli ktoś chce wiedzieć więcej o opcjach, atrybutach czy innych zaklęciach to namawiam, zachęcam, a nawet proszę o użycie man svnadmin czy svnadmin help. Informacja dla tych, którzy mają syndrom dnia wczorajszego i dzisiejszy dzień spędzają na mówieniu do siebie: “Kiedy to się wreszcie skończy” – nazwy katalogów są przykładowe, róbta co chceta, jeżeli chodzi o nazewnictwo i lokalizację.

mkdir -p /srv/svn

chown -R svn:svn /srv/svn 
svnadmin create repo 
chmod -R 2770 /srv/svn/repo/db

3. Praca z repozytorium

W tym punkcie pokażę podstawowe polecenia do obsługi i sposób załadowania danych do SVN.

Repozytorium jest puste niczym bęben więc ma revision 0. Jak to sprawdzić? Na ten przykład zrobić checkout. Zakładamy, że mamy założonego swojego użytkownika na tym serwerze, gdzie wykreowaliśmy repozytorium i łączymy się z nim za pomocą naszej lokalnej maszyny, z której przekazaliśmy nasze klucze SSH. Co jeszcze ważne – użytkownik powinien należeć do grupy svn, dla mniej wtajemniczonych w zaklęcia linuxa: useradd -a -G svn nazwa_usera.

Dalsze czynności wykonujemy na stacji klienta:

svn checkout svn+ssh://aciek@server/srv/svn/repo

cd repo 
svn info

Checked out revision 0.

oraz

Path: .

Working Copy Root Path: /home/aciek/svn/repo 
URL: svn+ssh://aciek@server/srv/svn/repo 
Relative URL: ^/ 
Repository Root: svn+ssh://aciek@server/srv/svn/repo 
Repository UUID: 0c13e719-a1e2-4559-85c2-e34ac33644b9 
Revision: 0 
Node Kind: directory 
Schedule: normal 
Last Changed Rev: 0 
Last Changed Date: 2022-10-13 17:21:39 +0200 (czw, 13 paź 2022)

svn add *

svn commit -m "to jest test" 
svn update

aciek@nielot:~/svn/repo$ svn add * 

A aciek.md 
aciek@nielot:~/svn/repo$ svn commit -m "to jest test" 
Adding aciek.md 
Transmitting file data .done 
Committing transaction... 
Committed revision 1. 
aciek@nielot:~/svn/repo$ svn update 
Updating '.': 
At revision 1. 
aciek@nielot:~/svn/repo$ svn log 
------------------------------------------------------------------------ 
r1 | aciek | 2022-10-13 17:53:52 +0200 (czw, 13 paź 2022) | 1 line 
 
to jest test 
------------------------------------------------------------------------

To by było na tyle, jeżeli chodzi o ręczne dodawanie. Teraz chciałbym jeszcze pokazać jedną rzecz, czyli import wielu plików lub drzewa katalogów tak just in case. Aby to zademonstrować utworzyłem sobie katalog svn w lokalizacji $HOME/tmp/ a w nim umieściłem kolejny katalog z plikami, które będziemy chcieli zaimportować do SVN. W tym przypadku jest to mark i pliki o masce markdown*. Co należy uczynić, aby dorzucić do naszego repozytorium ten katalog z zawartością. Nic prostszego, wystarczy będąc w kopii roboczej repozytorium uruchomić polecenie svn import z odpowiednimi atrybutami, gdzie między innymi wskażemy użytkownika test jako tego który oddaje źródła. Co jeszcze? Zaktualizujemy kopię roboczą i sprawdzimy sobie:

svn import ~/tmp/svn/ svn+ssh://test@server/srv/svn/repo -m "test 2"

svn update 
svn log

aciek@nielot:~/tmp/svn/mark$ svn import ~/tmp/svn/ svn+ssh://test@server/srv/svn/repo -m "test 2"

Adding . 
Adding (bin) markdown1.docx 
Adding markdown1.md 
Adding (bin) markdown2.docx 
Adding markdown2.html 
Adding (bin) markdown2.pdf 
Committing transaction... 
Committed revision 2. 
aciek@nielot:~/svn/repo$ svn update 
Updating '.': 
A mark 
A mark/markdown1.docx 
A mark/markdown1.md 
A mark/markdown2.docx 
A mark/markdown2.html 
A mark/markdown2.pdf 
Updated to revision 2. 
aciek@nielot:~/svn/repo$ svn log 
------------------------------------------------------------------------ 
r2 | test | 2022-10-14 23:24:53 +0200 (pią, 14 paź 2022) | 1 line 
 
test 2 
------------------------------------------------------------------------ 
r1 | aciek | 2022-10-13 17:53:52 +0200 (czw, 13 paź 2022) | 1 line 
 
to jest test 
------------------------------------------------------------------------

Git – nie GitHub czy GitLab

Na początek wytłumaczę, o co mi chodzi, że tak się czepiam nomenklatury w postaci rozróżnienia Git, GitHub i GitLab. Znam takich, którzy twierdzą, że to jedno i to samo. Odpowiedź brzmi: Nie, tak nie jest, a czym tak właściwie są postaram się przedstawić w słowach jak najbardziej przyswajalnych dla każdego:

• Git to system kontroli wersji
• GitHub to repozytorium w chmurze oparte na systemie kontroli wersji Git, gdzie główny nacisk kładziony jest, aby serwis posiadał najwyższą dostępność i wydajność.
• GitLab to repozytorium oparte na systemie kontroli wersji Git, które dostępne jest zarówno jako serwis internetowy, jak i jest możliwość instalacji serwisu na własnych zasobach. System oferuje dodatkowe funkcje.

To tyle, jeżeli chodzi o część teoretyczno-wyjaśniającą i możemy przejść do konkretów, czyli praktyki.

1. Instalacja

Tak jak w przypadku SVN skupiam się na dwóch rodzinach Linuxa więc:

• RedHat:

  yum install git dnf install git

• Debian:

  apt install git

Tym razem od razu zakładam, że się udało i możemy przejść dalej.

2. Konfiguracja

Żeby usystematyzować to powiem tylko, że pokażę Wam najszybszy sposób konfiguracji repozytorium na serwerze zdalnym a cała gawiedź w postaci zainteresowanych sobie je sklonuje i będzie mogło się do niego dostawać protokołem SSH. Bierzmy się zatem do dzieła.

Tak jak poprzednio w celach administracyjno-porządkowych zakładamy użytkownika i grupę dla repozytorium np. git.

groupadd git

useradd -g git -s /bin/bash -c "User Git" -m git

mkdir -p /srv/git/repo.git

cd /srv/git/repo.git 
git init --bare

• to jest z –bare:

  git@server:/srv/git/repo.git$ ls -la   total 40   drwxrwxr-x  7 git git 4096 Oct 15 09:44 .   drwxrwxr-x 12 git git 4096 Oct 15 09:44 ..   drwxrwxr-x  2 git git 4096 Oct 15 09:44 branches   -rw-rw-r--  1 git git   66 Oct 15 09:44 config   -rw-rw-r--  1 git git   73 Oct 15 09:44 description   -rw-rw-r--  1 git git   23 Oct 15 09:44 HEAD   drwxrwxr-x  2 git git 4096 Oct 15 09:44 hooks   drwxrwxr-x  2 git git 4096 Oct 15 09:44 info   drwxrwxr-x  4 git git 4096 Oct 15 09:44 objects   drwxrwxr-x  4 git git 4096 Oct 15 09:44 refs

• to jest bez opcji:
  

  aciek@nielot:~/git/repo$ ls -la   total 12   drwxrwxr-x 3 aciek aciek 4096 paź 15 09:49 .   drwxrwxr-x 4 aciek aciek 4096 paź 15 09:54 ..   drwxrwxr-x 7 aciek aciek 4096 paź 15 09:50 .git​

W zasadzie – z punktu widzenia administratora – to z rzeczy podstawowych byłoby na tyle. Pamiętajcie tylko aby byli pozakładani użytkownicy, którzy będą się łączyć z repozytorium, no i żeby należeli do grupy git (analogicznie do SVN wystarczy na tych już istniejących, którzy mają korzystać z repo wykonać polecenie: usermod -a -G git nazwa użytkownika).

3. Praca z repozytorium.

Ruszmy zatem nasze szanowne cztery litery, aby wypełnić to repozytorium. Jak już wspominałem na początku, Git ma architekturę rozproszoną, zatem to co w tym momencie nam potrzeba to klon repozytorium. Mam nadzieję, że zajrzeliście do dokumentacji, bo jak nie to jest kolejny ku temu powód, czyli jak zrobić klona i to via SSH (mam również nadzieję, że już wymieniliście się kluczami używając polecenia ssh-copy-id z serwerem, gdzie znajduje się repozytorium Git). Wróćmy do klonowania (dla leniwców podpowiedź: man git-clone lub git clone --help). Klonowanie jest proste jak budowa cepa: stworzymy sobie katalog roboczy i wykonamy polecenie, które to zrobi:

mkdir -p /home/aciek/git/

cd /home/aciek/git/ 
git clone aciek@server:/srv/git/repo.git

aciek@nielot:~/git$ git clone aciek@stach:/srv/git/repo.git

Cloning into 'repo'... 
warning: You appear to have cloned an empty repository. 
aciek@nielot:~/git$ ls -l 
total 4 
drwxrwxr-x 3 aciek aciek 4096 paź 15 17:51 repo 
aciek@nielot:~/git$ cd repo 
aciek@nielot:~/git/repo$ ls -la 
total 12 
drwxrwxr-x 3 aciek aciek 4096 paź 15 17:51 . 
drwxrwxr-x 3 aciek aciek 4096 paź 15 17:51 .. 
drwxrwxr-x 7 aciek aciek 4096 paź 15 17:51 .git

aciek@nielot:~/git/repo$ git status

On branch master 
 
No commits yet 
 
nothing to commit (create/copy files and use "git add" to track)

git add .git statusgit commit -m "to jest test"

aciek@nielot:~/git/repo$ git add .

aciek@nielot:~/git/repo$ git status 
On branch master 
 
No commits yet 
 
Changes to be committed: 
 (use "git rm --cached <file>..." to unstage) 
 new file: aciek.md 
 
aciek@nielot:~/git/repo$ git commit -m "to jest test" 
 
*** Please tell me who you are. 
 
Run 
 
 git config --global user.email "[email protected]" 
 git config --global user.name "Your Name" 
 
to set your account's default identity. 
Omit --global to set the identity only in this repository. 
 
fatal: unable to auto-detect email address (got 'aciek@nielot.(none)')

git config user.name "aciek"

git config user.email "[email protected]" 
git commit -m "to jest test"

aciek@nielot:~/git/repo$ git config user.name "aciek"

aciek@nielot:~/git/repo$ git config user.email "[email protected]" 
aciek@nielot:~/git/repo$ git commit -m "to jest test" 
[master (root-commit) 847c4b8] to jest test 
 1 file changed, 1 insertion(+) 
 create mode 100644 aciek.md

aciek@nielot-work:~/git/repo$ git log

commit 847c4b8dfcb1fc6fcb393ed3c3d53f0364149305 (HEAD -> master) 
Author: aciek <[email protected]> 
Date: Sat Oct 15 18:32:55 2022 +0200 
 
 to jest test

• git pull - zaciągnięcia zmian z repozytorium zdalnego (origin) do naszej kopii lokalnej
• git push - wypchnięcie zmian z naszego lokalne do repozytorium zdalnego

Zatem, jeżeli w tym momencie wykonamy git push oraz git log to będziemy mieli następujący wynik:

commit 847c4b8dfcb1fc6fcb393ed3c3d53f0364149305 (HEAD -> master, origin/master)

Author: aciek <[email protected]> 
Date: Sat Oct 15 18:32:55 2022 +0200 
 
 to jest test

Po pierwsze dlatego, że bardzo często widzę, i to jak się okazuje nie jestem w tym widzeniu osamotniony, że wielu robi czary mary i cuda na kiju w wyuzdanych technologiach a łapie się na tym, że brakuje im podstaw.

Po drugie, żeby pokazać, że nie jest to trudne i nie trzeba od razu używać kombajnów czy armat, żeby dać sobie radę. Oczywiście w takim rozwiązaniu nie ma wielu feature’ów np. dostępnych w GitLabie, ba, niema nawet interfejsu graficznego tylko rozwiązania systemowe, ale (według mnie) nie potrzeba rozwiązań rodem z NASA, aby radzić sobie z repozytoriami – w prostocie też jest metoda.

Po trzecie linia poleceń jest – zaprawdę powiadam Wam – bardzo fajna i nie trzeba wszystkiego wyklikiwać. No i może jeszcze jedno – o czym zdaje się, że już wspominałem – przez to klikanie ludziska przestali wiedzieć co się dzieje pod spodem a z doświadczenia wiem, że prędzej czy później taka wiedza się przydaje.

Trzymajcie się ciepło i Niech reguła KISS będzie z Wami, bo nie trzeba komplikować wszystkiego.

PS Żadna myszka nie ucierpiała podczas tworzenia tego artykułu … klawiatura miała gorzej :P :)