Przejdź do treści

Git

Article image
Nardastudio article git background
Autor: NardaStudio Data: 06 Nov 2019

Najpierw GIT

Pierwszym krokiem do nabycia umiejętności dobrej obsługi systemu kontroli wersji GIT, jest zrozumienie działania lokalnego repozytorium. Związanych z nim takich pojęć jak working directory, staging area, czym jest revision, commit, itd. Istotną rzeczą jest branch, czyli odgałęzienie. W projekcie może ich być wiele. Warto w tym celu na początek przeczytać jeden z pierwszych rozdziałów książki na oficjalnej stronie GIT dostępnej online za darmo (1.3 Getting Started - What is Git?).

Głowna strona projektu: https://git-scm.com

Na początku informacja, iż na ten moment używam wersji 2.17.1 zainstalowanej na Linux'ie. W przypadku sprawdzenia wersji wystarczy użyć komendy git version. Położenie instalacji GIT'a (np. w celu dostępu do pliku konfiguracyjnego) w przypadku systemu Linux sprawdzamy komendą which git.

Help!

Samo wpisanie polecenia git wyświteli krótką informację dotyczącą podstawowych poleceń. Jednak pierwszym ważnym argumentem, który na poczatku bardzo przydaje się w nauce GIT'a jest help znacząco ułatwiający możliwość poznania całego asortymentu dostępych komend. Umożliwa także lekturę dostępnych w programie tutoriali. Uruchomienie samego polecenia git help rozwija listę podstawowych komend wraz z objaśnieniami, ale warto nauczyć się używać polecenia git help wraz z innymi argumentami.

Przykładowe użycie:

  • git command help - wyświetli nam pomoc (instrukcję użycia) wskazanej komendy.
  • git help -a - pokaże listę wszystkich dostępnych komend, których znaczenie możemy sprawdzić powyższym przykładem.
  • git help -g - rozpisuje listę dostępnych poradników. Warto zaplanować sobie na początku lekturę każdego z nich.
  • git command -h - wyrzuca skróconą wersję pomocy odnoszącą się dla wskazanej komendy.

Konfiguracja i tworzenie repozytorium

Po instalacji oprogramowania GIT na naszym komputerze istotne jest wykonanie konfiguracji globalnie. Konfguracja lokalnie odbywa się w folderze danego projektu. Plikiem odpowiadającym za konfigurację naszego repozytorium jest plik .gitconfig Aktualne ustawienia uzyskamy wywołując git config --global -l lub git config --local -l. Warto zapoznać się z dostępymi argumentami konfiguracji używając dodatkowego argumentu help.

Należy pamiętać o:

  • git config --global user.name "User Name" - konfiguracja nazwy użytkownika. W przypadku większych projektów pracując w firmie z innymi, najlepiej ustawić swoje imię i nazwisko.
  • git config --global user.email email@email.com - konfiguracja adresu email dla użytkownika.
  • Powyższe informacje są zapisywane w momencie commit'u, czyli wiadomo przez kogo commit został wykonany.
  • Lista dostępnych argumentów wraz z opisem jest dostępna pod adresem https://git-scm.com/docs/git-config lub po wywołaniu git help config.

Planujemy zainicjować repozytorium, a następnie je rozwijać w folderze naszego projektu. Wywołujemy w tym celu komendę git init. Utworzony katalog .git odpowiada za całe lokalne repozytorium projektu. Usunięcie katalogu .git spowoduje utratę naszego lokalnego repozytorum, czyli całą historię zmian. Natomiast jeżeli chcemy wykluczyć poszczególne pliki aby nie były śledzone w naszym repozytorium, koniecza będzie edycja pliku .gitignore. Plik ten jest ważny w przypadku projektów takich jak np. Symfony, Drupal, Wordpress.

W przestrzeni roboczej

Pracujemy nad projektem zmieniając pliki, więc aby sprawdzić aktualny stan zmienionych plików (które zostały zmienione lub oczekują na dodanie do poczekalni) sprawdzamy komendą git status.

git add pozwala nam zmienione pliki dodać do poczekalni (staged), gdzie będą oczekiwać na commit. Możemy użyć git add changed_file.txt aby dodać do poczekalni pojedyńczy plik, jednak użycie git add . spowoduje dodanie wszystkich pików.

Komenda git diff file_name pokaże różnice/zmiany w wymienionym pliku. Lub w zależności od argumentów można zobaczyć zmiany pomiędzy commitami.

Po zakończeniu zmian i dodaniu plików do poczekalni wywołujemy git commit -m "Our short message about commit". W tym momencie zatwierdzamy zmiany i dodajemy krótkie info dotyczące zmian w commicie.

Aby uzyskać wgląd do listy zapisanych commit'ów wpisujemy git log. Możemy formatować listę na wiele sposobów używając odpowiednich argumentów, np. git log --pretty="oneline" lub git log --oneline.

Każdy zapisany commit posiada unikalny identyfikator, autora, datę oraz krótką notkę. Dzięki identyfikatorom lub datom można przeszukiwać zmiany, np. git show commit_ID

Bardzo ważnym elementem przy pracy z systemem kontroli wersji GIT są gałęzie. Dzięki nim możemy w łatwy sposób tworzyć oddzielne wersje zmian. Do obsługi gałęzi służą między innymi git branch, git checkout, git merge, git rebase. Idealnym rozwiązaniem do nauki w praktyce jest interaktywny tutorial Learn Git Branching.

GitHub - zdalne repozytoria

Aby dodać zdalne repozytorium utworzone wcześniej na koncie GitHub dla naszego projektu wykonujemy polecenie git remote add origin https://remote-repo.git. Natomiast samo git remote pokaże dodane już zdalne repozytoria.

Pomocnym źródłem wiedzy związanym z GitHub'em jest GitHub Learning Lab.

Przykłady poleceń

  • git clone https://link-to-repo - kopiuje zdalne repozytorium do lokalnego katalogu.
  • git push - wysyłamy zmiany do zdalnego repozytorium.
  • git push origin master - wysyłamy zmiany do zdalnego repozytorium, którego nazwą/aliasem jest origin a master gałęzią.
  • git fetch - pobieramy zmiany ale nie scala ich z lokalnym repozytorium.
  • git pull - odwrotnie do fetch, pobiera zmiany oraz scala je z lokalnym repozytorium.

Readme.md (markdown file)

Jest to plik będący opisem repozytorium jak i jego dokumentacją. Warto więc znać podstawowe zasady pisania takiego pliku. Pomocny w tym celu będzie link Mastering Markdown.

Przydatne linki

Ta strona nie jest kompatybilna z twoim urządzeniem. Uruchom stronę na komputerze lub nowszym urządzeniu.