Git - podstawy systemu kontroli wersji
Ta strona wymaga aktualizacji, informacje na niej zawarte mogą być niezgodne z prawdą.
W tym jakże krótkim wpisie chciałbym przedstawić podstawową obsługę systemu kontroli wersji Git. Podstawowym zadaniem Git-a jest monitorowanie zmian oraz umożliwienie wycofania modyfikacji w danym pliku.
Podstawy lokalnego systemy kontroli wersji Git
Folder z danymi, na których pracujemy po zainstalowaniu repozytorium staje się pierwszą warstwą pracy z Git. Tę warstwę nazywamy working directory (ang. katalog roboczy). Natomiast samo repozytorium, które umożliwni nam pracę z Git instalujemy poniższym poleceniem.
xf0r3m@K52F:~/Dokumenty/landisk $ git init
Czym jest repozytorium? Repozytorium to ukryty katalog wewnątrz katalogu roboczego. W nim znajdują się zapisane i przechowane w odpowiedni sposób zamiany wprowadzone w plikach katalogu roboczego. Po zainstalowaniu repozytorium w katalogu, w którym jakieś pliki już istnieją możemy je dodać wybiórczo, korzystając z poniższego polecenia:
xf0r3m@K52F:~/Dokumenty/landisk $ git add landisk.sh
lub dodać wszystkie pliki z katalogu, wykorzystując to polecenie:
xf0r3m@K52F:~/Dokumenty/landisk $ git add .
Nowe pliki są automatycznie zauważane przez Git, jako zmiany w katalogu roboczym.
Podając . (kropkę) jako argument polecenia add, dodaliśmy wszystkie plik do naszego repozytorium. Rozważmy teraz taki scenariusz, że nasze repozytorium zawiera bardzo dużo plików. Moglibyśmy skorzystać z polecenia git add . jednak w naszym repozytorium znajdują się pliki, których nie chcemy monitorować, w tej sytuacji możemy regulować, które pliki mają być monitorowane, a które nie. Służy temu specjalny plik Git-a, umieszczany w repozytorium: .gitignore. W tym pliku umieszczamy nazwy katalogów, plików (w nazwach plików możemy używać symbolu wieloznaczności *) lub ścieżki, które mają zostać pominięte podczas monitorowania katalogu przez Git. Pamiętać należy o tym że ten plik jest ukryty.
Wszystkie zauważone przez Git zmiany możemy sprawdzić za pomocą polecenia:
xf0r3m@K52F:~/Dokumenty/landisk $ git status
Z informacji zwróconych przez polecenie, możemy sprawdzić stan naszych plików, teraz po dodaniu plików do monitorowania mamy informacje o zamianach w naszym katalogu roboczym. Korzystanie z Git-a, nie jest wcale trudne, sam Git daje nam podpowiedzi, aby usunąć jakiś plik z obecnego stanu przejściowego wydajemy poniższe polecenie. Uwaga! Usunięcie plików ze stanu przejściowego nie spowoduje przywrócenia pliku przed zmianami. Plik zostanie pominięty podczas zapisywania go zapisywania go w repozytorium:
xf0r3m@K52F:~/Dokumenty/landisk $ git rm --cached <nazwa_pliku>
Czym jest ten stan przejściowy? Otóż podczas pracy z Git-em, operujemy tak naprawdę na trzech płaszczyznach.
Pierwszy z nich to katalog roboczy, na plikach w tym katalogu są dokonywane przez nas zmiany, te zmiany są rejestrowane w tak zwanym stanie przejściowym. Ten stan przechowuje wszystkie zmiany przed zapisaniem ich w repozytorium, tworzy tymczasowe migawki plików, w których dokonano zmian. Ze stanu przejściowego bardzo łatwo cofnąć zmiany wystarczy jedno polecenie.
xf0r3m@K52F:~/Dokumenty/landisk $ git checkout landisk.sh
Podając jako argument nazwę pliku przywracamy tylko konkretny plik, warto zauważyć że po wydaniu tego polecenia, zmiany zarejestrowane przez Git w pliku zostają wycofane oraz zostaje on usunięty ze stanu przejściowego. Zamiast nazwy pliku możemy użyć kropki (.), wtedy przywrócimy wszystkie pliki. Warto pamiętać, że polecenie checkout wycofuje zmiany tylko z stanu przejściowego. To polecenie nie działa na nowe pliki. Jak widzimy możemy sobie swobodnie balansować pomiędzy stanem przejściowym, a katalogiem roboczym. W edytorze naciskamy ctrl+s, Git od razu wyłapuje zmianę, testujemy, coś nie działa, wydajemy polecenie git checkout, zmiany zostały wycofane, kiedy jednak jesteśmy pewni że nasz kod działa możemy dokonać zatwierdzenia. Zatwierdzenie jest dokonywane z plików, których zmiany zostały uwzględnione w stanie przejściowym.
To co znajduje się w stanie przejściowym sprawdzamy poleceniem git status. Zatwierdzenie dokonuje takiej stałej migawki, którą będzie mogli przywrócić nie zależnie od tego ile zmian było już plikach projektu, kiedy przy poleceniu checkout możemy cofnąć tylko ostatnią zmianę. Aby dokonać zatwierdzenia, wydajemy następujące polecenie.
xf0r3m@K52F:~/git_lab/repo1$ git commit -am "Pierwsze pliki" [master (root-commit) 7f5135a] Pierwsze pliki 2 files changed, 9 insertions(+) create mode 100644 imiona create mode 100644 kolory
Opcja -a w poleceniu powoduje uwzględnienie wszystkich zmodyfikowanych plików, z kolei -m powoduje dodanie komentarza do zatwierdzenia. Sprawdzenie stanu repozytorium dokonujemy za pomocą polecenia
xf0r3m@K52F:~/git_lab/repo1$ git log --pretty=oneline 7f5135af8bca2dad1d9f1d7c7db34990a6115efa (HEAD -> master) Pierwsze pliki
Jak widzimy repozytorium jest takim miejscem przechowywania zatwierdzeń. Teraz dokonamy zmian w plikach aby mieć jeszcze jedno zatwierdzenie w repozytorium. Po wiedzmy że w tym zatwierdzeniu powinny być dwa pliki zmienione nie tylko jeden. Z repozytorium pliki możemy przywrócić na dwa sposoby: do stanu przejściowego (git reset --soft) oraz do katalogu roboczego (git reset --hard), jeśli chcemy dodać po prostu plik wycofując stare zatwierdzenie i utworzyć nowe tym razem obejmujące wszystkie pliki, wybierzemy opcje --soft. Jako argument opcji --soft podajemy to zatwierdzenie, z którego chcemy przywrócić pliki, nie te które ostatnio wprowadziliśmy, w którym znajduje się nasz błąd.
1f7ecc0bca359431bf11493358fd1f87e24fc341 (HEAD -> master) Zmiany w imionach 7f5135af8bca2dad1d9f1d7c7db34990a6115efa Pierwsze pliki
Więc jako argument opcji --soft podamy ID zatwierdzenia 7f5135. Po przywróceniu zatwierdzenie opisane jako "Zmiany w imionach" przestaje istnieć. Słowo o commit ID. Każde zatwierdzenie jest identyfikowane przez Git za pomocą długiego ciągu znaków zapisanego w systemie heksadecymalnym, który występuje w pierwszej kolumnie danych zwracanych przez polecenie git log --pretty=oneline. Commit ID jest sześcioma pierwszymi znakami tego ciągu.
To kiedy wydamy polecenie
xf0r3m@K52F:~/git_lab/repo1$ git status
Otrzymamy taką odpowiedź (o ile nie wprowadziliśmy żadnych w innych plikach) od Git.
On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) zmodyfikowany: imiona
Jeśli zmieniliśmy jakieś pliki to odpowiedź będzie taka jak poniżej:
On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) zmodyfikowany: imiona Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) zmodyfikowany: kolory
Teraz aby dodać te pliki należy wydać polecenie git add <nazwa_pliku> w tym przypadku są to kolory.
Na tym przykładzie lepiej widać jak działa stan przejściowy. Kiedy plik zostaje zmodyfikowany, trafia on do stanu przejściowego jednak nie jest oznaczony jako plik do zatwierdzenia, dlatego wydajemy polecenie commit wraz opcją -a, aby nie musieć dodawać plików jako "do zatwierdzenia". Tylko zatwierdzać wszystkie zmodyfikowane pliki. Gdybyśmy nie stosowali tej opcji, to należało by każdy nieoznaczony plik dodać za pomocą polecenia add.
Pozostała w sumie ostatnia podstawowa czynność jaką możemy wykonać czyli przywrócić pliki z repozytorium bezpośrednio do katalogu roboczego. Aby wykonać tą czynność wydajemy polecenie.
xf0r3m@K52F:~/git_lab/repo1$ git reset --hard 7f5135
Przy tym poleceniu z ID commit-u jest identycznie. Ten commit, który wybraliśmy jest oznaczony jako HEAD, czyli główny commit repozytorium.
Prywatne, zdalne repozytorium
Teraz utworzymy sobie w prosty sposób zdalne repozytorium, będzie to wymagać jedynie kilka poleceń w powłoce, ponieważ połączenia będziemy realizować za pomocą SSH.
Na naszym serwerze sprawdzamy czy jest dostępny Git. Jeśli jest dostępny to możemy przejść od razu do tworzenie nowego użytkownika. Jeśli po wydaniu polecenia git dostajemy informacje o tym, że nie można odnaleźć polecenia, to wydajemy polecenie odpowiednie dla naszej dystrybucji, które zainstaluje Git w systemie.
ubuntu@gitssh:~$ sudo apt install git
Kiedy Git znajduje się już w systemie, lub został przed chwilą zainstalowany, tworzymy użytkownika, który w swoim folderze domowym będzie przechowywał nasze repozytoria.
ubuntu@gitssh:~$ sudo adduser git
W tym momencie (najlepiej zaraz po utworzeniu użytkownika), podać nasz klucz publiczny do logowania przez SSH nowemu użytkownikowi.
xf0r3m@K52F:~$ ssh-keygen xf0r3m@K53F:~$ ssh-copy-id git@gitssh
Teraz kiedy już możemy zalogować się bez hasła, zalogujemy się na serwer jako git. Następnie tworzymy nowy katalog o nazwie git-shell-commands oraz nadamy mu odpowiednie uprawnienia.
git@gitssh:~$ mkdir git-shell-commands git@gitssh:~$ chmod 775 git-shell-commands
Wylogowujemy się z tego użytkownika, a następnie logujemy się na użytkownika z uprawnieniami administracyjnymi, po zalogowaniu w pliku /etc/passwd zmieniamy domyślną powłokę dla użytkownika git z /bin/bash na /usr/bin/git-shell. Zapisujemy zmiany w pliku.
git:x:1001:1001:git,,,:/home/git:/usr/bin/git-shell
Teraz kiedy wydamy polecenie su git ukaże nam się taki obraz (aby wyjść wydajemy polecenie exit):
git>
Aby jednak uruchomić normalną powłokę UNIX-ową dla tego użytkownika musimy zalogować się jako root. Następnie wydać poniższe polecenie.
root@gitssh:/home/ubuntu$ su -s /bin/bash - git
Teraz zalogujemy się do powłoki bash na użytkowniku git i utworzymy katalog naszego repozytorium:
git@gitssh:~$ mkdir example.git
Wewnątrz utworzonego przez nas katalogu wydajemy poniższe polecenie:
git@gitssh:~/example.git$ git --bare init
Po wydaniu tego polecenia, nasze repozytorium jest gotowe, w celach testowych możemy przesłać na niego pusty plik README.
xf0r3m@K52F:/git_lab/repo3$ touch README.md xf0r3m@K52F:/git_lab/repo3$ git init Initialized empty Git repository in /home/xf0r3m/git_lab/repo3/.git/ xf0r3m@K52F:/git_lab/repo3$ git add . xf0r3m@K52F:/git_lab/repo3$ git commit -am "first commit" [master (root-commit) 5bafc2b] first commit 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.m xf0r3m@K52F:/git_lab/repo3$ git remote add origin ssh://git@192.168.56.211/~/example.git xf0r3m@K52F:/git_lab/repo3$ git push origin master Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 209 bytes | 209.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To ssh://192.168.56.211/~/example.git * [new branch] master -> master
Powyżej mamy listing z terminala, użyłem tutaj dwóch nowych poleceń, które często będą wykorzystywane przez nas podczas pracy ze zdalnym repozytorium. Pierwsze polecenie:
xf0r3m@K52F:/git_lab/repo3$ git remote add origin ssh://git@192.168.56.211/~/example.git
dodaje pod nazwą origin adres do zdalnego repozytorium do naszej lokalnej konfiguracji Git. Dzięki tej nazwie łatwiej będzie nam wpychać (przesyłać) nasze repozytorium na zdalny Git. Drugie polecenie:
git push origin master
powoduje wepchnięcie gałęzi o nazwie master (głównego repozytorium) na zdalne repozytorium, którego adres kryje się po nazwą origin.
Zdalne repozytorium po SSH jest dobre kiedy w szybki, prosty i bezpieczny sposób musimy stworzyć prywatne repozytorium. Jednak do pracy w wieloma użytkownikami jest ono nadzwyczaj nie wygodne, ponieważ każdy użytkownik musi zalogować się jako root, aby utworzyć kolejne repozytorium.
Obecnie dostępne są trzy sprawne pakiety oprogramowania zapewniające usługę zdalnego repozytorium obsługiwane z poziomu WWW. Taki GitHub tylko że hostowany na swoich serwerach. Poniżej przedstawię instalację wszystkich trzech pakietów. Obsługa nie jest trudna, wystarczy czytać ze zrozumieniem i nie bać się eksperymentować. Jak co się uszkodzi to zawsze możemy zainstalować to jeszcze raz z poniższych poradników lub mieć z tyłu głowy zapisane, aby zrobić kopie zapasową naszego środowiska testowego przed wprowadzeniem jakieś poważnej zmiany, prawda ?
GitLab
Na początek weźmiemy pod lupę pierwszy najbardziej zaawansowany i w sumie najłatwiejszy do zainstalowania - GitLab. Moim środowiskiem testowym to przedstawienia instalacji była maszyna wirtualna VirtualBox z Ubuntu Server 20.04, nie radze używać kontenerów chyba że uprzywilejowanych, ponieważ GitLab podczas swojej instalacji zmienia kilka ustawień kernela.
Dokonujemy aktualizacji repozytoriów z paczkami oprogramowania następnie instalujemy niezbędne w systemie pakiety. W Ubuntu Server 20.04, wymagane oprogramowanie jest już zainstalowane, jednak kiedy korzystamy z 18 lub 16.04 warto upewnić się czy te pakiety są już w naszym systemie.
xf0r3m@gitlab:~$ sudo apt update xf0r3m@gitlab:~$ sudo apt install curl openssh-server ca-certificates tzdata
Instalacje Postfix możemy pominąć.
Teraz dodamy repozytoria GitLab do naszych repozytoriów systemowych.
xf0r3m@gitalab:~$ curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
Właściwa instalacja GitLab odbywa się za pomocą APT. Jednak przed wydaniem polecenia należy zdefiniować w zmiennej EXTERNAL_URL, adres pod którym nasz GitLab będzie dostępny.
xf0r3m@gitlab:~$ sudo EXTERNAL_URL="http://192.168.0.211" apt install gitlab-ce
Instalacja GitLab może potrwać nawet do dwóch godzin w zależności od łącza internetowego oraz mocy obliczeniowej naszego sprzętu. O zakończeniu instalacji zostaniemy poinformowani odpowiednim komunikatem. Po zainstalowaniu możemy przejść pod adres, który podaliśmy w zmiennej EXTERNAL_URL. Po załadowaniu strony, zostaniemy poproszeni o zdefiniowanie hasła dla użytkownika administracyjnego GitLab. Teraz możemy zalogować się, podając w nazwie użytkownika nazwę root. Jeśli zdecydujemy się na użycie GitLab jako naszego zdalnego repozytorium, to należało by użyć HTTPS. Aby to zrealizować należy:
- Zmienić w pliku /etc/gitlab/gitlab.rb wartość opcji EXTERNAL_URL. Zmieć protokół na HTTPS następnie podać nazwę domeny, pod którą GitLab będzie dostępny.
xf0r3m@gitlab:~$ sudo vi /etc/gitlab/gitlab.rb
Wewnątrz pliku odszukujemy opcję
EXTERNAL_URLi ustawiamy jej wartość na adres pod którym będzie widoczny GitLab.EXTERNAL_URL="https://gitlab.morketsmerke.net"
- Utworzyć katalog ssl wewnątrz katalogu /etc/gitlab, nadać mu uprawnienia 755 następnie przekopiować do tego katalogu nasze pliki certyfikatu.
xf0r3m@gitlab:~$ sudo mkdir -p /etc/gitlab/ssl xf0r3m@gitlab:~$ sudo chmod 755 /etc/gitlab/ssl xf0r3m@gitlab:~$ sudo cp *.pem /etc/gitlab/ssl
- Następnie wydajemy polecenie:
xf0r3m@gitlab:~$ sudo gitlab-ctl reconfigure
Po zakończeniu rekonfiguracji GitLab powinien być dostępny pod adresem jaki podaliśmy w zmiennej EXTERNAL_URL, po protokole HTTPS.
Kolejnym oprogramowaniem umożliwiającym nam łatwe utworzenie ogólnodostępnego zdalnego repozytorium Git-a będzie Gogs.
Gogs
Instalacje Gogs-a w naszym systemie rozpoczynamy od zainstalowania jakiegoś pakietu bazodanowego np. MySQL.
xf0r3@gogs:~$ sudo apt install mysql-server mysql-client
Następnie pobieramy najnowszą paczkę z Gogs-em z https://gogs.io/docs/installation/install_from_binary
xf0r3m@gogs:~$ wget https://dl.gogs.io/0.12.1/gogs_0.12.1_linux_amd64.tar.gz
Po pobraniu rozpakowujemy paczkę.
xf0r3m@gogs:~$ tar -xzvf gogs_0.12.1_linux_amd64.tar.gz
W katalogu gogs/scripts będzie plik o nazwie mysql.sql. Otwieramy go i dopisujemy dwie linie.
CREATE USER 'gogs'@'localhost' IDENTIFIED BY 'Trudn3Hasl0DOMysql'; GRANT ALL ON gogs.* TO 'gogs'@'localhost';
Zapisujemy zmiany w pliku, następnie tworzymy bazę dla Gogs.
xf0r3m@gogs:~/gogs/scripts$ sudo mysql < mysql.sql
Teraz tworzymy nowego użytkownika np. o nazwie git. To na jego katalogu domowym będą tworzone repozytoria użytkowników oraz to z jego uprawnieniami będzie uruchamiany Gogs.
xf0r3m@gogs:~$ sudo adduser git
Kopiujemy na jego katalog domowy naszą paczkę z Gogs.
xf0r3@gogs:~$ sudo cp gogs_0.12.1_linux_amd64.tar.gz /home/git
Przechodzimy na jego katalog domowy, albo przez sudo su i następnie su git lub bezpośrednio su git. Tam wypakowujemy naszą paczkę.
xf0r3m@gogs:~$ su git Password: git@gogs:~$ tar -xzvf gogs_0.12.1_linux_amd64.tar.gz
Teraz możemy uruchomić nasz serwer. Uwaga! Jeśli uruchamiamy naszego Gogs-a w środowisku produkcyjnym, to przed pierwszym uruchomieniem serwera należy wykonać czynność opisane poniżej, w przeciwnym wypadku możemy przejść do uruchomienia serwera.
Poniżej przedstawię jak należy skonfigurować Nginx jako reverse proxy, aby nasz serwer Gogs był widoczny pod konkretnym adresem oraz pod klasycznym portem HTTPS.
Na początku w katalogu /etc/ssl tworzymy katalog o nazwie gogs.
xf0r3m@gogs:~$ sudo mkdir -p /etc/ssl/gogs
Następnie kopiujemy do niego pliki certyfikatu
xf0r3@gogs:~$ sudo cp *.pem /etc/ssl/gogs
Teraz instalujemy nginx.
xf0r3m@gogs:~$ sudo apt install nginx
Po zainstalowaniu pakietu, w katalogu /etc/nginx/sites-enabled tworzymy plik o nazwie gogs następnie w nim wklejmy poniższą konfiguracje.
server {
listen 443 ssl;
server_name git.example.com;
root /var/www/html/system/nginx-root; # Used for acme.sh SSL verification (https://acme.sh)
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:3000;
}
ssl on;
ssl_certificate /etc/ssl/gogs/fullchainX.pem;
ssl_certificate_key /etc/ssl/gogs/privkeyX.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_timeout 5m;
client_max_body_size 50m;
}
W pliku zmieniamy:
- server_name - podajemy nazwę, pod którą Gogs będzie widoczny.
- proxy_pass - podajemy adres oraz port, na którym nasłuchuje główny proces serwera Gogs
- ssl_certificate - podajemy ścieżkę do pliku certyfikatu
- ssl_certificate_key - podajemy ścieżkę do pliku klucza prywatnego certyfikatu.
Restartujemy nginx:
xf0r3m@gogs:~$ sudo systemctl restart nginx
Sprawdzamy czy serwer wystartował prawidłowo:
xf0r3m@gogs:~$ sudo systemctl status nginx
Jeśli nginx wystartował poprawnie lub uruchamiamy gogs dla celów testowych to możemy, uruchomić serwer a następnie instalacje Gogs, na którą wchodzimy przez adres zdefiniowany w parametrze server_name.
git@gogs:~$ gogs/gogs web 2020/09/13 08:54:43 [ WARN] Custom config "/home/git/gogs/custom/conf/app.ini" not found. Ignore this warning if you're running for the first time 2020/09/13 08:54:43 [TRACE] Log mode: Console (Trace) 2020/09/13 08:54:43 [ INFO] Gogs 0.12.1 2020/09/13 08:54:43 [TRACE] Work directory: /home/git/gogs 2020/09/13 08:54:43 [TRACE] Custom path: /home/git/gogs/custom 2020/09/13 08:54:43 [TRACE] Custom config: /home/git/gogs/custom/conf/app.ini 2020/09/13 08:54:43 [TRACE] Log path: /home/git/gogs/log 2020/09/13 08:54:43 [TRACE] Build time: 2020-08-27 07:07:30 UTC 2020/09/13 08:54:43 [TRACE] Build commit: 43fc8260850090b55d4ee2586a819b3b6c016279 2020/09/13 08:54:43 [ INFO] Run mode: Development 2020/09/13 08:54:43 [ INFO] Listen on http://0.0.0.0:3000
Do stworzenia w dużej mierze (90 kilku %) Gogs wykorzystano język programowania Go. Dlatego podobnie do aplikacji stworzonych w Node.js, Gogs startuje na wysokim porcie, aby mógł wystartować na porcie poniżej 1024 musi zostać uruchomiony jako root, co nie jest zalecane. Adres z portem 3000 na końcu przepiszemy do naszej przeglądarki zamiast zer, podstawimy adres naszej maszyny.
Po wpisaniu naszego zmienionego adresu w przeglądarkę, wyświetli nam się strona instalacyjna. Co zmieniamy?
- Hasło MySQL do użytkownika Gogs - musimy podać hasło jakie podaliśmy przy zakładaniu bazy.
- Nazwa aplikacji - według uznania.
- Domena - podajemy adres IP maszyny (w przypadku środowiska testowego) lub domenę (w przypadku środowiska produkcyjnego).
- Adres URL aplikacji - podobnie do domeny (w przypadku środowiska testowego) lub https://git.naszadomena.org (w przypadku środowiska produkcyjnego)
Po zainstalowaniu zostaniemy przyniesieni nas stronę logowania. Jednak naszą pracę z Gogs-em zaczniemy od utworzenia konta. Pierwszy zarejestrowany użytkownik dostaje uprawnienia administracyjne. Pod formularzem logowania znajduje się odnośnik kierujący nas do formularza rejestracji. Wypełniamy wszystkie pola i rejestrujemy użytkownika, po zarejestrowaniu zostaniemy przeniesieni z powrotem na stronę logowania, logujemy się nowo utworzonym użytkownikiem i mamy Gogs-a do dyspozycji.
Powiedzmy że mamy zainstalowany Gogs (w wersji produkcyjnej) i musimy wyłączyć nasz serwer. Po jego ponownym uruchomieniu i próbie połączenia z Gogs otrzymujemy błąd "502 Bad Gateway". Oznacza on mniej więcej tyle że proxy nie ma gdzie przekierować danych ponieważ usługa na podanym przez nas adresie i porcie nie odpowiada. Gogs nie został uruchomiony po starcie systemu. Musimy go uruchomić ręcznie. Jednak uruchamianie Gogs-a po każdym resecie serwera nie jest raczej mile widziane. Współczesne systemy, tak jak w moim przypadku Ubuntu posiadają bardzo zaawansowaną obsługę poziomów uruchomienia systemu jednym z nich jest systemd. Za uruchomienie konkretnych usług w danym momencie odpowiadają specjalne skrypty systemd, Gogs w swoich plikach instalacyjnych również posiada taki skrypt.
Aby dodać Gogs do autostartu, wystarczy że skopiujemy plik gogs.service z katalogu gogs/scripts/systemd do /etc/systemd/system następnie wydamy polecenie:
xf0r3m@gogs:~$ sudo systemctl enable gogs.service
W pliku nie musimy nic zmieniać, ponieważ tak zainstalowaliśmy Gogs-a, że nasze ścieżki do danych Gogs pokrywają się tymi w pliku usługi. To polecenie spowoduje zarejestrowanie nowej usługi na danym poziomie uruchomienia.
Ostatnim pakietem jaki będziemy instalować jest Gitea. Jej instalacja jest bardzo podobna do Gogs-a.
Gitea
A więc instalacje Gitei rozpoczynamy od zainstalowania na serwerze systemu bazodanowego może być to MySQL może być to MariaDB lub PostgreSQL.
xf0r3m@gitea:~$ sudo apt install mysql-client mysql-server
Następnym krokiem jest stworzenie bazy danych.
xf0r3m@gitea:~$ sudo mysql mysql> CREATE DATABASE gitea; -- ciach -- mysql> CREATE USER 'gitea'@'localhost' IDENTIFIED BY '2up3rT4jn3H4s|_0'; -- ciach -- mysql> GRANT ALL ON gitea.* TO 'gitea'@'localhost';
Kolejną czynnością jest utworzenie użytkownika, z którego uprawnieniami będziemy uruchamiać Giteę. W tym przypadku stworzymy użytkownika systemowego poniższym poleceniem.
xf0r3m@gitea:~$ sudo adduser --system --shell /bin/bash --group --disable-password --home /home/git git
Po stworzeniu użytkownika, możemy utworzyć niezbędne dla Gitei katalogi.
xf0r3m@gitea:~$ sudo mkdir -p /home/git/{custom,data,log}
xf0r3m@gitea:~$ sudo chown -R git:git /home/git
xf0r3m@gitea:~$ sudo chmod -R 750 /home/git
xf0r3m@gitea:~$ sudo mkdir /etc/gitea
xf0r3m@gitea:~$ sudo chown root:git /etc/gitea
xf0r3m@gitea:~$ sudo chmod 770 /etc/gitea
Po instalacji będziemy, musieli pamiętać o odebraniu uprawnień do zapisu w katalogu /etc/gitea oraz w pliku /etc/gitea/app.ini.
Teraz przelogujemy się na użytkownika git.
xf0r3m@gitea:~$ sudo su root@gitea:/home/xf0r3m# su git
Bezpośrednio do katalogu domowego ściągamy plik binarny Gitei. Kiedy plik znajdzie się już na serwerze możemy go uruchomić i zainstalować Giteę.
git@gitea:~$ GITEA_WORK_DIR=/home/git ./gitea web -c /etc/gitea/app.ini
Nie musimy przejmować się brakiem pliku /etc/gitea/app.ini. Zostanie on utworzony podczas instalacji. Kiedy nasz serwer wystartuje możemy przejść pod http://<ip_serwera>:3000. Naszym oczom ukaże się strona startowa, podobna do tej, którą znamy z Gogs. Wygląda to trochę jakby nie trzeba było tego instalować, mamy w prawym górnym rogu dwa odnośniki Zaloguj się oraz Zarejestruj się, z racji tego iż musimy zarejestrować pierwszego użytkownika (pierwszy zarejestrowany użytkownik zyskuje uprawnienia administracyjne) klikamy w odnośnik Zarejestruj sie i wyświetla nam się stroną instalacji, którą już znamy z Gogs. Uzupełniamy lub zmieniamy te pola, jakie zostały wymienione przy okazji Gogs-a. Po zainstalowaniu zostaniemy przekierowani na stronę logowania, klikamy odnośnik pod przyciskiem aby zarejestrować pierwszego użytkownika. Następnie możemy się już logować.
Dla Gitei również dostępny jest plik usługi po tym adresem https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service, w którym musimy zmienić parę opcji, m.in. wskazać jakiego systemy bazodanowego użyliśmy, aby wstrzymać uruchamianie Gitei do momentu uruchomienia bazy danych. Poniżej znajduje się zawartość pliku gitea.service przygotowana dla przedstawionej tutaj instalacji Gitei.
[Unit] Description=Gitea (Git with a cup of tea) After=syslog.target After=network.target ### # Don't forget to add the database service requirements ### # Requires=mysql.service #Requires=mariadb.service #Requires=postgresql.service #Requires=memcached.service #Requires=redis.service # ### # If using socket activation for main http/s ### # #After=gitea.main.socket #Requires=gitea.main.socket # ### # (You can also provide gitea an http fallback and/or ssh socket too) # # An example of /etc/systemd/system/gitea.main.socket ### ## ## [Unit] ## Description=Gitea Web Socket ## PartOf=gitea.service ## ## [Socket] ## Service=gitea.service ## ListenStream=<some_port> ## NoDelay=true ## ## [Install] ## WantedBy=sockets.target ## ### [Service] # Modify these two values and uncomment them if you have # repos with lots of files and get an HTTP error 500 because # of that ### #LimitMEMLOCK=infinity #LimitNOFILE=65535 RestartSec=2s Type=simple User=git Group=git WorkingDirectory=/home/git # If using Unix socket: tells systemd to create the /run/gitea folder, which will contain the gitea.sock file # (manually creating /run/gitea doesn't work, because it would not persist across reboots) #RuntimeDirectory=gitea ExecStart=/home/git/gitea web --config /etc/gitea/app.ini Restart=always Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/home/git # If you want to bind Gitea to a port below 1024, uncomment # the two values below, or use socket activation to pass Gitea its ports as above ### #CapabilityBoundingSet=CAP_NET_BIND_SERVICE #AmbientCapabilities=CAP_NET_BIND_SERVICE ### [Install] WantedBy=multi-user.target
Ten plik umieszczamy w katalogi /etc/systemd/system następnie wydajemy polecenie:
xf0r3m@gitea:~$ sudo systemctl enable gitea.service
Jeśli jeszcze tego zrobiśmy to teraz zatrzymamy naszą ręcznie uruchomioną Giteę, naciskając w oknie połaczonego z serwerem terminala Ctrl+c. Następnie wydajemy poniższe polecenia. Te polecenia zmieniają uprawnienia do pliku konfiguracyjnego Gitei.
xf0r3m@gitea:~$ sudo chmod 750 /etc/gitea xf0r3m@gitea:~$ sudo chmod 640 /etc/gitea/app.ini
Na końcu możemy uruchomić naszą usługę z Giteą.
xf0r3m@gitea:~$ sudo systemctl start gitea.service
Jeśli chcemy Giteę uruchomić w środowisku produkcyjnym, to przydałby się HTTPS. Reverse proxy dla Gitei uruchomiamy identycznie jak dla Gogs. Nawet możemy użyć tego samego pliku konfiguracyjnego.
Podsumowanie
Pomiędzy tymi trzema, który wybrać. Osobiście jeśli potrzebujemy na wczoraj skonfigurować ogólnodostępnego prostego zdalnego Gita, to wybrał bym Gogsa. Instaluje się go szybko i bez wiekszych problemów, prawdopodbnie zawiera wszystko co potrzeba.
Jeśli jesteśmy na prawdę dużymi leniami, lub nie dysponujemy żadną mocą obliczeniową, którą możemy swobodnie zarządzać z Internetu, to czwartą opcją najmniej bolesną pozostaje konto na GitHub.
~xf0r3m