Wybierz region
pl
  • PL
  • EN
Wydrukuj

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.

  1. 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

No i svn (w przypadku git będzie git co wydaje się być bardziej adekwatnie :) )

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

Cudownie mieć własne repozytorium SVN. Jedwabistość nasza nie zna granic.

  1. 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://[email protected]/srv/svn/repo

cd repo

svn info

I na wyjściu otrzymamy:

Checked out revision 0.

oraz

Path: .

Working Copy Root Path: /home/aciek/svn/repo

URL: svn+ssh://[email protected]/srv/svn/repo

Relative URL: ^/

Repository Root: svn+ssh://[email protected]/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)

Teraz już możemy się bawić. Dla przykładu utworzę w swoim ulubionym edytorze (vim) w katalogu kopii roboczej (checkout) pliczek aciek.md i dodamy go do repozytorium, następnie wykonamy commit i aktualizację kopii roboczej:

svn add *

svn commit -m "to jest test"

svn update

Czego wynikiem będzie:

[email protected]:~/svn/repo$ svn add * 

A aciek.md

[email protected]:~/svn/repo$ svn commit -m "to jest test"

Adding aciek.md

Transmitting file data .done

Committing transaction...

Committed revision 1.

[email protected]:~/svn/repo$ svn update

Updating '.':

At revision 1.

[email protected]:~/svn/repo$ svn log

------------------------------------------------------------------------

r1 | aciek | 2022-10-13 17:53:52 +0200 (czw, 13 paź 2022) | 1 line

 

to jest test

------------------------------------------------------------------------

Jak widać oddaliśmy nasze źródło do repozytorium użytkownikiem aciek (czego można było się spodziewać po wyniku polecenia svn info)

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://[email protected]/srv/svn/repo -m "test 2"

svn update

svn log

A wynik:

[email protected]:~/tmp/svn/mark$ svn import ~/tmp/svn/ svn+ssh://[email protected]/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.

[email protected]:~/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.

[email protected]:~/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

------------------------------------------------------------------------

Na tym koniec na dzisiaj, jeżeli chodzi o SVN i sposób na utworzenie repozytorium, oddawanie do niego czy nawet załadowanie źródłami.

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.

  1. 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

Tak jak i w przypadku SVN wybieramy lokalizację naszego repozytorium Git i tworzymy tam katalog a następnie inicjujemy powstanie czystego repozytorium. W tym miejscu – jak to zwykle bywa – zapraszam do zapoznania się z manualami polecenia git (man git lub git --help) dla konkretnej funkcji man git-init lub git init --help. Dobrze jest kolejne polecenia wykonywać za pomocą utworzonego użytkownika git tak, aby właścicielem i grupą do którą należą katalogi z repo był git. Jeśli tak nie jest, zawsze można to zmienić korzystając ze składni: chown -R git:git /srv/git/repo.git

mkdir -p /srv/git/repo.git

cd /srv/git/repo.git

git init --bare

Wytłumaczę najprościej, jak się da co tutaj robimy. Na początek tworzymy katalog repozytorium. Jak pewnie teraz widzicie nasze repozytorium nazwaliśmy repo. Udajemy się do nowoutworzonego katalogu i inicjujemy tworzenie repozytorium Git z opcją –bare czyli golasa, czyli takiego na którym programiści nie pracują, nazwijmy go wzorcowym, a ten “ubrany” jest repozytorium roboczym. Może zamiast tłumaczyć jaka jest różnica między inicjacją z opcją lub bez, unaocznię Wam to listując katalog repozytorium:

  • to jest z –bare:
    [email protected]:/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:
    [email protected]:~/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).

  1. 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 [email protected]:/srv/git/repo.git

Czego efektem będzie (pokazuję od razu z zawartością, żeby nie przedłużać i żeby była jasność, jak to wygląda):

[email protected]:~/git$ git clone [email protected]:/srv/git/repo.git

Cloning into 'repo'...

warning: You appear to have cloned an empty repository.

[email protected]:~/git$ ls -l

total 4

drwxrwxr-x 3 aciek aciek 4096 paź 15 17:51 repo

[email protected]:~/git$ cd repo

[email protected]:~/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

Tym optymistycznym akcentem mamy już miejsce, gdzie możemy tworzyć nasze źródła, utwory czy co tam chcecie. Oczywiście w tym momencie jest puste, można to zobaczyć za pomocą git status.

[email protected]:~/git/repo$ git status

On branch master

 

No commits yet

 

nothing to commit (create/copy files and use "git add" to track)

Zaletą takiego tworzenia repozytorium jest to, że właściwie już prawie wszystko jest skonfigurowane, bo repozytorium już wie, gdzie leży i jak się dostać do tego zdalnego. Jest właściwie tylko jedna (a właściwie 2 rzeczy, bo tego Git wymaga) do uzupełnienia. Chcecie wiedzieć czego brakuje? To spróbujcie zrobić to, co robiliśmy w przypadku SVN, czyli stworzymy plik (w moim przypadku aciek.md) i spróbujemy oddać go do repozytorium. Przykład poniżej:

git add .git statusgit commit -m "to jest test"
No i co się zadzieje? Git status tutaj nie był potrzebny, ale chciałem pokazać, że wykaże plik aciek.md jako ten, który zostanie potraktowany przez commit i znajdzie się jako pierwszy w naszym repozytorium. Jednak nie tym razem, właśnie ze względu na to o czym pisałem, czyli to czego Git wymaga:

[email protected]:~/git/repo$ git add .

[email protected]:~/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

 

[email protected]:~/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 '[email protected](none)')

Git musi wiedzieć z kim ma do czynienia, czyli co za delikwent chce coś oddać do repozytorium. Do tego potrzebuje użytkownika i adresu email a bez tego będzie uparcie kazał się nam odstosunkować od niego. Do tego służy git config, zresztą w output widać, że właśnie to podpowiada. Atrybut --global powoduje, że po ustawieniu będziemy - tak jak wypełniliśmy – przedstawiani w każdym repozytorium, do którego cokolwiek oddamy, jeżeli utworzymy bez --global zapisy będą dotyczyć tylko tego konkretnego repozytorium. Ustawmy właśnie tak i ponówmy próbę commit-a.

git config user.name "aciek"

git config user.email "[email protected]"

git commit -m "to jest test"

Na wyjściu otrzymamy:

[email protected]:~/git/repo$ git config user.name "aciek"

[email protected]:~/git/repo$ git config user.email "[email protected]"

[email protected]:~/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

I teraz, jak zajrzymy do repozytorium korzystając z opcji log dla git

[email protected]:~/git/repo$ git log

commit 847c4b8dfcb1fc6fcb393ed3c3d53f0364149305 (HEAD -> master)

Author: aciek <[email protected]>

Date: Sat Oct 15 18:32:55 2022 +0200

 

to jest test

W repozytorium już jest a właściwie w jego lokalnej kopii. Teraz wypadałoby wysłać to na nasz serwer i już będzie czadowo, bo inni też będą to mogli zobaczyć. Dlatego na koniec moich wypocin pokażę jeszcze dwa polecenia:

  • 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

No dobrze, na tym skończę, żeby nie zamęczyć Was na śmierć. Tylko jeszcze małe podsumowanie po co o tym wszystkim piszę. Jest ku temu kilka powodów – oczywiście poza tym, że lubię pisać :P

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 :)


Adam Paszkiewicz

Adam aka aciek, Ekspert ds. Technologii z Asseco Warszawa. Z technologiami związany od okresu dojrzewania (a ten był dawno temu) ale gotować i żeglować też potrafi. Rzeczy niemożliwe realizuje od ręki, na cuda trzeba chwilę zaczekać. Uważa, że w życiu jak i w pracy dobrze mieć kupę radości ... z przewagą radości.


Wydrukuj