GIT – podstawy

GIT jest to system kontroli wersji, który w obecnych czasach wykorzystywany jest do wszelkich zadań związanych z tworzeniem oprogramowania oraz innych zadań związanych z samą kontrolą wersji. Dzięki niemu jesteśmy w stanie śledzić zmiany w plikach, jak i również współpracować nad projektem z innymi członkami zespołu. Dzięki GIT masz możliwość przywracania plików do poprzednich wersji. Sprawdzać kto wprowadzał w nie zmiany, jak i również łączyć dokonane przez osoby współpracujące.

Oznacza to, że korzystając z GIT, posiadamy na naszym lokalnym dysku kopię całego repozytorium. Ta kopia zawiera wszelkie wersje, którymi w łatwy sposób możemy zarządzać. Dlatego to narzędzie tak naprawdę nie wymaga żadnego zewnętrznego oprogramowania czy też serwera. Jednak wykorzystuje się go najczęściej w połączeniu z platformą github, na której wspomniane repozytoria się magazynuje. W ten sposób wysyłamy naszą treść do projektu, na którym wspólnie pracujemy. Jednak samym githubem oraz tematem magazynowania naszych repozytoriów GIT zajmę się w jednym z ostatnich punktów tego artykułu.

W związku z kontrolowaniem wersji jesteśmy w stanie, pracując w grupie przeprowadzać wiele testów. W razie jakiegoś błędu w łatwy sposób powrócić do poprzedniego, działającego stanu. Dlatego też GIT stał się narzędziem niezbędnych wśród osób pracujących nad projektem. Nie tylko programiści z niego korzystają. Przydaje się w wielu przypadkach i administratorom systemowych na przykład przy tworzeniu obrazów dockerowych czy też plików kubernetesa.

Pierwotnym jego założeniem było zarządzanie rozwojem jądra Linuksa. GIT został wymyślony przez Linusa Torvaldsa w tym właśnie celu. Jednak bardzo szybko został wykorzystany w innych sferach IT.

W związku z powyższym znajomość, chociaż w zakresie podstawowym tego narzędzia jest niezbędne. Dlatego, też postanowiłem napisać artykuł, aby pokazać, w jaki sposób korzystać z GIT. Mam nadzieję, że się wam spodoba i co najważniejsze, przyda. Bez dalszego wstępu przejdźmy do konkretnych działań.

 

 

 

 

Instalacja GIT

Instalację aplikacji przeprowadzę w systemie Linux. Bazować będę na dwóch popularnych dystrybucjach jak Debian oraz Red Hat Enterprise Linux. Jednak sposób instalacji możesz zastosować również do innych. Dlatego, jeżeli korzystać z dystrybucji Ubuntu to powinieneś móc zainstalować aplikację w ten sam sposób jak w przypadku Debiana. Tak samo w przypadku Fedory, możesz zainstalować w identyczny sposób jak w przypadku Red Hat Enterprise Linux. Natomiast jeżeli korzystasz z dystrybucji niewymienionej w przykładach i niepokrewnej, podmień menadżer pakietów przeze mnie użytego.

Przyznam, że nie spotkałem się z dystrybucją, która nie posiadałaby w swoim repozytorium tego narzędzia. Jednak gdybyś napotkał problemy związane z brakiem możliwości instalacji w omawiany sposób, wejdź na stronę https://git-scm.com/downloads. Pod podanym adresem znajdziesz wszelkie inne sposoby dostępne na różne dystrybucje jak i również paczkę do ściągnięcia.

W celu instalacji pakietu GIT musisz zalogować się na swoje konto root lub skorzystać z sudo.

Debian i powiązane

W przypadku systemu Debian instalujesz GIT w następujący sposób:

sudo apt install git

Red Hat Enterprise Linux i powiązane

W przypadku systemu Red Hat Enterprise Linux instalujesz GIT w następujący sposób:

sudo yum install git

Tak jak zapewne zauważyłeś, został podmieniony tylko menadżer pakietów, który wykorzystywany jest w danej dystrybucji.

Weryfikacja

Po przeprowadzeniu instalacji zawsze warto ją zweryfikować. Dlatego w wierszu poleceń wpisujemy:

git --version
git version 2.30.2

Po otrzymaniu informacji zwrotnej jesteś pewny, że zainstalowałeś GIT. Pamiętaj jednak, że jako wynik mogłeś otrzymać inną wersję. To, jaka znajduje się w danej dystrybucji, jest zależna od niej samej, a dokładnie od osób dodających wersje paczek. Na obecną chwilę najnowszą wersją jest 2.38.2, natomiast system Debian 11 Bullseye, ma wersję trochę starszą.

Wstępna konfiguracja

W celu korzystania z funkcji, które poznamy w dalszej części tego materiału, musimy ustawić w programie swój adres mailowy oraz nazwę użytkownika.

Aby ustawić adres e-mail, wprowadzasz polecenie:

git config –global user.email „you@example.com”

Aby ustawić nazwę, imię i nazwisko korzystamy z polecenia:

git config –global user.name „Your Name”

Są to dwie wymagane konfiguracje, aby móc wykonywać wszystkie czynności związane z GIT. Opcji do ustawienia w powyższy sposób jest o wiele więcej. Natomiast w tym materiale pokazuję tylko te niezbędne.

Po wykonaniu powyższej konfiguracji możemy przejść do dalszej części artykułu.

Twoje pierwsze repozytorium

Przyznaje, gdy pierwszy raz chciałem skorzystać z GIT, nie wiedziałem co i jak, dlatego zrezygnowałem z jego korzystania. Najlepiej byłoby napisać, że GIT nie jest trudnym narzędziem, o ile zna się podstawowe polecenia. Jednak chyba przyznasz, że to dotyczy wszystkich programów. O ile znamy podstawowe polecenia, wiemy jak z nich korzystać i do czego służą. Stąd też jest ono dla nas proste. Natomiast chcę pokazać, stopniowo w jaki sposób GIT stanie się prosty dla Ciebie. Dlatego przejdźmy do działa.

Pierwsze co musisz zrobić, by powstało twoje repozytorium to, stworzyć katalog na dysku. W większości wypadków tę czynność wykonuje w konsoli, dlatego przejdź do katalogu domowego lub innego, gdzie takie repozytorium będziesz chciał, by powstało. Następnie skorzystać z polecenia do stworzenia katalogu jak w poniższym przykładzie:

mkdir askomputer
cd askomputer/

Po jego stworzeniu przejdźmy do niego, ponieważ wewnątrz, będziemy prowadzili dalsze działania. To w tym katalogu będą znajdowały się wszystkie pliki dotyczące projektu, nad którym będziemy pracowali. Jednak na razie jest on pusty. Aby to zmienić, musimy zainicjować w nim repozytorium GIT. Robimy to przy pomocy polecenia:

git init
podpowiedź: Użycie „master” jako nawy początkowej gałęzi. Ta domyślna nazwa gałęzi
podpowiedź: może się zmienić. Aby ustawić nazwę początkowej gałęzi do użycia we
podpowiedź: wszystkich nowych repozytoriach, co uciszy ten komunikat, wykonaj:
podpowiedź:
podpowiedź:     git config --global init.defaultBranch <nazwa>
podpowiedź:
podpowiedź: Tradycyjnie było „master”, a inne popularne to „main”, „trunk”
podpowiedź: i „development”. Nazwę właśnie utworzonej gałęzi można zmienić tym poleceniem:
podpowiedź:
podpowiedź:     git branch -m <nazwa>
Zainicjowano puste repozytorium Gita w /home/darki/askomputer/.git/

Wywołując polecenie w prezentowany sposób, została mu przypisana standardowa nazwa master. W związku z tym, aby nie pojawił się więcej, ten komunikat powinniśmy skorzystać z polecenia:

git config --global init.defaultBranch <nazwa>

W miejscu <nazwa> podajemy standardową nazwę gałęzi, jaka będzie nadawana przy tworzeniu repozytorium. Osobiście polecam, by była to nazwa master lub main. Przy następnych repozytoriach przez nas tworzonych nie pojawi się ten komunikat.

W celu weryfikacji czy repozytorium zostało dodane, wprowadzamy polecenie służące do wyświetlenia listy plików ukrytych w katalogu:

ls -a
.  ..  .git

Jak widać na powyższym przykładzie, został utworzony katalog .git. W związku z tym nasze pierwsze repozytorium zostało dodane.

Najważniejsze polecenia

Nim przejdziemy dalej, chcę pokazać, najważniejsze polecenia, które w codziennej pracy na pewno się przydadzą. Dlatego zapoznaj się z poniższą listą.

1. git clone – jest to polecenie, które umożliwia klonowanie istniejącego repozytorium GIT. Umieszcza on na naszym lokalnym dysku kopię repozytorium. Jeżeli nigdy nie tworzyłeś repozytoriów przy pomocy GIT, to najprawdopodobniej korzystałeś z tego polecenia.
2. git add – to polecenie sprawia, że dodajemy do naszego obszaru repozytorium pliki, jednak ich jeszcze nie akceptujemy. Można to określić jako miejsce, gdzie przetrzymuje się te pliki w celu ich zaakceptowania. Dzięki takiemu stanowi rzeczy jesteś w stanie wybrać które elementy chcesz, aby zostały dodane, a które nie.
3. git commit – polecenie służy do zapisania zmian i dodania plików do repozytorium. Pobiera wszystkie pliki, które są w stanie przejściowym i zapisuje jako nową wersję. To w tym miejscu powstaje możliwość śledzenia zmian wprowadzonych w plikach.
4. git push – polecenie służy do przesyłania plików z lokalnego systemu do zdalnego oraz wprowadzania zmian w repozytorium zdalnym. Dzięki niemu mamy możliwość rozpoczęcia współpracy z innymi członkami zespołu lub innymi zainteresowanymi projektem.
5. git pull – polecenie można pomylić z clone, ponieważ służy również do pobrania. Jednak w tym wypadku pobierane są zmiany ze zdalnego serwera i łączy się je z lokalnym repozytorium. Jest niezwykle ważne w przypadku pracy w zespole, ponieważ uaktualnia nasze lokalne repozytorium o najnowsze zmiany wprowadzone przez innych.

W tym paragrafie chciałem pokazać pięć najważniejszych poleceń GIT, nim przejdziemy do części bardziej praktycznej. Niektóre z nich posiadają swoje rozwinięcia oraz dodatkowe opcje. Natomiast wielu nie wypisałem. Jednak niektóre z nich pojawią się w dalszej części tego materiału.

Dalsza część naszego pierwszego repozytorium

Teraz jak już znamy podstawowe polecenia, to możemy przystąpić do tworzenia dalszego rozwijania naszego lokalnego repozytorium. Dlatego będąc w katalogu, stwórzmy plik compose.yaml i w nim umieśćmy kod:

nano -w compose.yaml

Kod:

version: '3'
services:
  web:
    image: httpd:2.4
    ports:
      - "80:80"
    volumes:
      - ./public-html:/usr/local/apache2/htdocs/

Prezentowany kod służy do tworzenia multi kontenerów w dockerze. Obecnie zawiera on jeden kontener, ale za niedługo wprowadzimy w nim pewne zmiany. Po dodaniu pliku, aby sprawdzić co, się dzieje w naszym repozytorium, możemy skorzystać z polecenia:

git status
Na gałęzi master

Jeszcze nie ma zapisów

Nieśledzone pliki:
  (użyj „git add <plik>...”, żeby uwzględnić, co zostanie złożone)
    compose.yaml

nie dodano nic do złożenia, ale są nieśledzone pliki (użyj „git add”, aby śledzić)

Stworzyliśmy plik, który umieściliśmy w katalogu, gdzie znajduje się repozytorium. Jednak ten plik nie został w żaden sposób dodany do niego. GIT zauważył to i wypisał swoje zalecenia. Dlatego dodajmy go do tak zwanego stanu przejściowego. Robimy to przy pomocy polecenia:

git add compose.yaml

Nie otrzymamy żadnej odpowiedzi zwrotnej, tylko automatycznie przejdziemy do wiersza wpisywania poleceń w konsoli. Ponownie użyjmy polecenia status:

git status
Na gałęzi master

Jeszcze nie ma zapisów

Zmiany do złożenia:
  (użyj „git rm --cached <plik>...”, aby wycofać)
    nowy plik:   	compose.yaml

Otrzymujemy informacje od GIT, że nadal nie ma żadnego zapisu do repozytorium, ale odnajduje on możliwą zmianę. Od razu podpowiada, że jeżeli jest to błąd, możemy wycofać się z tego przy pomocy wskazanego polecenia. Wycofajmy w takim razie nasz plik:

git rm --cached compose.yaml

Jeżeli ponownie wprowadzisz polecenie status, to zauważysz, że plik jest w stanie przed dodaniem. Dlatego ponów powyższe polecenia tak, aby przywrócić go do stanu przejściowego.

Jeżeli jesteśmy już pewni, że dany plik chcemy dodać do naszego repozytorium, korzystamy z polecenia:

git commit -m 'Serwer APACHE'
[master (zapis-korzeń) e4f770b] Serwer APACHE
 1 file changed, 8 insertions(+)
 create mode 100644 compose.yaml

Zgodnie z uzyskaną informacją plik został dodany do repozytorium i na gałęzi master jest rozpoznawalny pod nazwą Serwer APACHE. Musisz mi teraz coś wybaczyć. Nie wprowadziłem jeszcze tematu branches czy też określonych przed chwilą gałęzi. Dlatego w tym miejscu zapamiętaj, że master jest to pewnego rodzaju miejsce, w którym zapisywane są zmiany. W naszym wypadku w tym miejscu został zapisany nasz plik, który określiliśmy jako Serwer Apache. Branches czy też gałęziami zajmiemy się w następnym podrozdziale, gdzie to wytłumaczę dokładniej.

Sprawdźmy, jak to wygląda, po wprowadzeniu polecenia status:

git status
Na gałęzi master
nic do złożenia, drzewo robocze czyste

Czyli wszystkie zmiany zostały wprowadzone.

Branches / Gałęzie w GIT

Możliwe, że pamiętasz na samym początku tego artykułu, po wprowadzeniu polecenia init, wyskoczyła informacja o braku ustawionej gałęzi. Napisałem wtedy, że musimy określić aplikacji standardową gałąź. GIT po instalacji nie posiada ustawionej standardowej gałęzi, dlatego musieliśmy mu taką przypisać.

Jednak nadal nie wiesz, co to jest gałąź. Otóż dzięki funkcji branches GIT pozwala użytkownikowi pracować nad niezależnymi liniami rozwoju aplikacji jednocześnie. Bardziej to można zobrazować w taki sposób, że tworzymy trzy gałęzie rozwojowe noszące nazwę stable, testing, development. Nad każdą z tych można pracować jednocześnie. Czyli wprowadzając jakiekolwiek zmiany, będą one widoczne tylko na danej gałęzi. W związku z tym projekt znajdujący się w jednym katalogu lub magazynie zdalnym rozpoznawany jest jako repozytorium. Posiada kilka gałęzi rozwoju, z których korzystać i pracować można w tym samym czasie.

Teraz zacznijmy bardziej praktycznie. Na początku wypiszmy gałęzie, jakie już posiadamy:

git branch -a
* master

W kolorze zostanie wyświetlona aktywna gałąź. U mnie jest to kolor zielony. Tak jak się mogliśmy spodziewać, posiadamy tylko jedną gałąź master. Stwórzmy teraz drugą o nazwie testing:

git branch testing

Ponownie wyświetlmy listę gałęzi:

git branch -a
* master
  testing

Posiadamy już dwie gałęzie. Obecnie znajdujemy się na gałęzi master, jak wskazuje przykład. Dlatego przejdźmy na nowo stworzoną:

git checkout testing
Przełączono na gałąź „testing”

Poznaliśmy kolejne nowe polecenie służące do zmian gałęzi w GIT.

Teraz wyświetlmy listę branchy:

git branch -a
  master
* testing

Tym razem zarówno gwiazdka, jak i nazwa testing jest w kolorze. Oznacza to, że obecnie znajdujemy się na tej gałęzi. Możesz zapytać i co nam to daje? Otóż wprowadźmy teraz pewne zmiany do pliku, który stworzyliśmy:

nano -w compose.yaml

version: '3'
services:
  web:
    image: httpd:2.4
    ports:
      - "80:80"
    volumes:
      - ./public-html:/usr/local/apache2/htdocs/
    depends_on:
      - db
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
    volumes:
      - ./mysql-data:/var/lib/mysql/

Zastąp poprzedni, prezentowanym w powyższym przykładzie. Następnie wpiszmy znane przez nas polecenie status:

git status
Na gałęzi testing
Zmiany nie przygotowane do złożenia:
  (użyj „git add <plik>...”, żeby zmienić, co zostanie złożone)
  (użyj „git restore <plik>...”, aby odrzucić zmiany w katalogu roboczym)
    zmieniono:   	compose.yaml

brak zmian dodanych do zapisu (użyj „git add” i/lub „git commit -a”)

Nim przejdziemy dalej, porozmawiajmy o tym, co się tak naprawdę dzieje. Gdy tworzymy nową gałąź pliki znajdujące się na tej, na której się znajdowaliśmy przy jej tworzeniu, są automatycznie do niej dodawane. Dlatego teraz zarówno na gałęzi master, jak i testing plik compose się znalazł.

Po sprawdzeniu statusu otrzymaliśmy informację od GIT, że możemy cofnąć wprowadzone zmiany. Dlatego zróbmy to teraz:

git restore compose.yaml

Po wprowadzeniu tego polecenia, jeżeli nazwę pliku właściwie wprowadziliśmy, zostaniemy przeniesieni do nowego wiersza, gdzie możemy wpisywać polecenia. Jeżeli zerkniesz teraz do pliku, compose.yaml to będzie on posiadał kod z pierwszego przykładu.

cat compose.yaml
version: '3'
services:
  web:
	image: httpd:2.4
	ports:
  	- "80:80"
	volumes:
  	- ./public-html:/usr/local/apache2/htdocs/

Ponownie dodajmy kod, który usunęliśmy do pliku. Następnie dodajmy nasz plik do stanu przejściowego:

git add compose.yaml

Jeżeli wprowadzisz polecenie status, otrzymasz informację, że nadal możesz cofnąć wprowadzone zmiany. My jednak dodamy już plik z wprowadzonymi zmianami do naszego repozytorium. Robimy to przy pomocy znanego nam polecenia:

git commit -m 'Serwer APACHE with MySQL'
[testing a673faa] Serwer APACHE with MySQL
 1 file changed, 9 insertions(+)

Mamy już stworzone dwa commity. Każde z nich było utworzone na dwóch różnych gałęziach. Aby wyświetlić listę dostępnych, korzystamy z polecenia:

git log
commit a673faa9fc709d1133a225211162268e024e9543 (HEAD -> testing)
Author: Krzysztof Godzisz <k.godzisz@wp.pl>
Date:   Fri Dec 16 12:11:24 2022 +0100

	Serwer APACHE with MySQL

commit e4f770b60260691909f801db2f4742962b3ea392 (master)
Author: Krzysztof Godzisz <k.godzisz@wp.pl>
Date:   Fri Dec 16 11:03:55 2022 +0100

	Serwer APACHE

Zwróćcie uwagę, na to, co znajduje się w nawiasie po ID commita. Pierwszy dostępny jest w testing drugi w master. Oznacza to, że zmiany, jakie wprowadziliśmy przed chwilą, dotyczą tylko obecnej gałęzi. Jednak sprawdźmy to i przejdźmy na gałąź master:

git checkout master

Sprawdźmy zawartość pliku:

cat compose.yaml
version: '3'
services:
  web:
	image: httpd:2.4
	ports:
  	- "80:80"
	volumes:
  	- ./public-html:/usr/local/apache2/htdocs/

Zawiera tylko ten kod, który utworzyliśmy na samym początku. Jak widzisz, jest to, banalnie proste, o ile zna się polecenia, wiesz do czego, służą oraz jak się nimi posługiwać.

Przełączmy się teraz na gałąź testing.

git checkout testing

Stwórzmy nowy branch/gałąź:

git branch development

Przełączamy się na nowo stworzoną gałąź:

git checkout development

Teraz dodamy dwa pliki. Jednak nim do tego przystąpimy, sprawdźmy, czy na pewno znajdujemy się na nowej gałęzi:

git branch -a
* development
  master
  testing

Wszystko się zgadza, dlatego dodamy dwa nowe pliki. Pierwszy z nich to compose z nginx + mysql:

nano -w compose-nginx.yaml 

version: '3'

services:
  nginx:
    image: nginx
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - mysql

  mysql:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: my_database

Natomiast drugi będzie to zwykły plik tekstowy:

nano -w tekst

Uczę się posługiwać GIT

Po wyświetleniu statusu mamy dwa pliki do dodania:

git status
Na gałęzi development
Nieśledzone pliki:
  (użyj „git add <plik>...”, żeby uwzględnić, co zostanie złożone)
    compose-nginx.yaml
    test

nie dodano nic do złożenia, ale są nieśledzone pliki (użyj „git add”, aby śledzić)

Możemy zrobić to pojedynczo lub przy użyciu jednego polecenia z odpowiednią opcją:

git add --all

To proste polecenie nada wszystkim plikom status pośredni. Jednak zmieńmy jeszcze nazwę pliku z apache i mysql tak, aby było wiadomo, co w nim się znajduje:

mv compose.yaml compose-apache.yaml

Jeżeli wyświetlisz status, to dowiesz się, że będziesz musiał ponownie zaakceptować zmiany. Dlatego korzystasz z polecenia add dla pojedynczego pliku lub dodajesz opcje –all i wszystkie pliki znajdą się w stanie przejściowym.

Pozostało stworzyć nowy commit, by pliki znalazły się w repozytorium:

git commit -m 'Development first files'

Jeżeli zerkniesz w logi przy pomocy polecenia git logs, to na liście pojawi się nowy commit.

Inną bardzo przydatną opcją jest możliwość scalania branchy. Polega to na kopiowaniu z jednej gałęzi do drugiej. Aby tego dokonać, na początku przełączmy się na gałąź, do której chcemy się przełączyć:

git checkout master

Następnie scalamy gałąź master z gałęzią development:

git merge development

Jeżeli wyświetlisz zawartość katalogu, będąc na gałęzi master, to zobaczysz, że zawiera on te same pliki co branch development.

GIT i Github – przesyłanie do zdalnego repozytorium

Miejsc, gdzie możesz magazynować swoje repozytoria, jest kilka. Jednak jednym z najbardziej popularnych jest github.com. Git został stworzony do współpracy grupowej, dlatego posiada proste narzędzie służące do tego celu. Jednak aby z niego skorzystać, na początku musisz takie stworzyć. Dlatego, jeżeli jeszcze nie masz, załóż konto na github.com. Następnie po zalogowaniu, na stronie odnajdź część, w której znajduje się przycisk create new repository. Powyżej wspomnianego przycisku znajduje się pole tekstowe, do którego musisz wprowadzić nazwę twojego repozytorium. Ja swoje nazwałem naukagit. Jeżeli zamierzasz nazwać swoje inaczej, to pamiętaj jego nazwę. W związku z tym, że repozytorium nie musi być prywatne, zaznaczam opcję public. Następnie klikam przycisk create a new repository. Po utworzeniu repozytorium zostaniesz przeniesiony do strony, gdzie masz wszystko opisane krok po kroku.

Większość z tej pracy już wykonaliśmy, jednak warto przeanalizować, to co proponuje nam github. Dzięki niemu odnajdziemy jeszcze jeden sposób dodawania plików do stanu przejściowego. Otóż możemy stosować:

git add .

zamiast

git add --all

Nie wprowadzałem tej możliwości wcześniej, ponieważ na początku bardziej czytelnie prezentuje się z opcją opisową niż z kropką. Jednak częściej spotkasz się z rozwiązaniem zawierającym kropkę. Którą Ty będziesz stosował, zależy od twoich preferencji. Oba rozwiązania działają identycznie.

Nadeszła pora by do naszego stworzonego repozytorium zdalnego dodać pliki z naszego repozytorium lokalnego. Pierwsze co wykonujemy, to podajemy jego adres:

git remote add origin https://github.com/kgodzisz/naukagit.git

Następnie do naszego zdalnego repozytorium wypychamy wszystkie pliki znajdujące się w gałęzi master:

git push -u origin master

Zostaniesz poproszony o podanie loginu, a następnie hasła. Jednak po wprowadzeniu prawidłowych danych otrzymasz informację:

remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Uwierzytelnienie nie powiodło się dla „https://github.com/kgodzisz/naukagit.git/”

Możliwość logowania prezentowany sposób została wyłączona 13 Sierpnia 2021. W obecnej chwili możesz na przykład stworzyć token. Jednak ten sposób jest bardzo zbliżony do podania hasła, z którego github zrezygnował. W związku z tym, że większość z nas korzysta z SSH, skonfigurujemy githuba w taki sposób, byśmy mogli skorzystać z klucza publicznego. Dlatego, jeżeli jesteś nadal zalogowany na platformie github, po prawej stronie najedź na swój awatar i kliknij, aby rozwinąć menu. Następnie wybierz opcję settings. Pojawi się nowa strona. Z menu z lewej strony kliknij link SSH and GPG keys. Kliknij przycisk new ssh key. Na nowej stronie w miejscu title wpisujesz dowolną opisową nazwę. Natomiast w miejscu key kopiujesz swój klucz SSH, który powinieneś mieć wygenerowany. Key Type pozostawiasz bez zmian.

Jeżeli nie wiesz, w jaki sposób wygenerować klucz SSH napisałem o tym artykuł, który znajduje się pod adresem (link jak będzie).

Po wykonaniu powyższych czynności klikamy w button add SSH key.

W związku z tym, że autoryzacja będzie występowała przy pomocy SSH, musimy zmienić dostęp do naszego repozytorium. Jednak jeżeli chcemy nadać mu tę samą nazwę, musimy na początku usunąć wcześniej stworzony dostęp. W celu wyświetlenia wszystkich możemy skorzystać z polecenia:

git remote -v

Zostanie wyświetlona lista wszystkich ustawionych repozytoriów, z którymi możemy nawiązać połączenie. W związku z tym, że nie chcemy łączyć się przy pomocy HTTPS, tylko przy pomocy SSH to usuwamy wcześniej ustawiony dostęp. Robimy to przy pomocy polecenia:

git remote rm origin

Teraz pod tą samą nazwą dodajemy dostęp do repozytorium przy pomocy SSH:

git remote add origin git@github.com:kgodzisz/naukagit.git

Następnie wysyłamy nasze lokalne repozytorium, z gałęzi master do github:

git push -u origin master

Zostaniemy poproszeni o podanie hasła do klucza SSH. Jeżeli skonfigurowaliśmy wszystko właściwie, pliki zostały przesłane. Zerknij teraz na github do swojego repozytorium. Jeżeli wykonałeś wszystko krok po kroku ze mną, powinieneś mieć trzy pliki. Zalecane jest do każdego repozytorium tworzenie pliku README, którego tutaj nie utworzyliśmy.

Przeanalizuj wszystko, co dotychczas zrobiliśmy. Natomiast dodając jeszcze od siebie, zdalnych repozytoriów możesz mieć setki. Przy ustawianiu dostępu w miejscu użytego przeze mnie origin ustawiasz inną nazwę.

Podsumowanie

Czy git jest pomocny tylko dla programistów? Tutaj się bardzo nie zgodzę. Wiecie, ostatnio bardzo dużo piszę, zresztą czytasz to. W mojej pracy copywriterskiej przydaje się on również, a przecież ja nie programuje. Dlatego myślę, że każdy z nas znajdzie w swojej pracy zastosowanie gita. Oczywiście o ile jego praca polega na tworzeniu jakichś plików.

Cały ten artykuł nie polegał na wypisaniu poleceń i opisaniu ich zastosowania. To znajdziesz w dokumentacji. Dlatego wiele poleceń poznałeś w trakcie. Nie zostały one w jakiś sposób ułożone według zastosowania. Pomimo tego, że opisałem podstawy GIT, to chciałem, aby był on bardziej praktyczny. Abyś swobodnie mógł swoje projekty umieszczać na github i udostępniać je znajomych bądź innym zainteresowanym. Natomiast ten sposób prezentacji ma również swój inny cel. Wiem, że nie opisałem wszystkiego. GIT jest narzędziem bardzo rozbudowanym jednak ten sposób opisu mam nadzieję, że otworzy dla Ciebie drogę do dalszego jego poznawania. Podstawy znasz! Uważam to za najważniejsze. Natomiast resztę mam nadzieję, że będziesz w stanie wyczytać z dokumentacji lub korzystając z pomocy wbudowanej w polecenie.

Chcesz wiedzieć więcej na temat administracji? Przeczytaj nasze artykuły, a także weź udział w kursach!