Ten wpis bierze udział w konkursie na najlepszy artykuł o elektronice lub programowaniu, którego partnerem jest firma PCBWay (popularny producent prototypów PCB). W puli nagród karty podarunkowe Allegro o wartości 2300 zł. Sprawdź więcej informacji na temat konkursu »
Pracuję sam, po co mi kontrola wersji?
Jeżeli słyszałeś już o Gicie, prawdopodobnie wiesz że jest doskonałym narzędziem w projektach nad którymi pracuje wiele osób. A co jeśli pracujesz sam? Czy w takim razie Git ma coś do zaoferowania? Tak. Nie musisz nawet łączyć się z internetem żeby korzystać z jego dobrodziejstw. Pomyśl o następujących scenariuszach:
Chcesz wrócić do wersji kodu sprzed 2 tygodni, czwartek o 17:12. Albo do wczorajszej, bo wczoraj jeszcze działało a jesteś absolutnie pewien że nic nie ruszałeś
Nie pamiętasz po co modyfikowałeś dany plik, albo nawet konkretną linię
Fragment programu nie działa, nie wiesz od kiedy. Git pozwoli Ci znaleźć konkretną zmianę, która spowodowała błąd
Chcesz wykonać mały eksperyment na boku, bez obaw że zepsujesz "właściwą" wersję programu
Chcesz móc sprawdzić jak wyglądały Twoje postępy w projekcie
Chcesz łatwo opublikować swój kod w serwisie GitHub aby się nim pochwalić lub pozwolić skorzystać komuś innemu.
We wszystkich tych miejscach Git oferuje swoje wsparcie. Dlatego powstał ten artykuł - aby pomóc osobom które piszą programy jako dodatek do swojej pracy w poznaniu podstaw gita i skorzystania z jego dobrodziejstw. Nie ma żadnych specjalnych wymagań - każdy powinien być w stanie skorzystać Jeżeli jesteś zaawansowanym użytkownikiem gita to nic ciekawego tutaj nie znajdziesz, uprzedzam
Model pracy
Praca z gitem opiera się na użyciu repozytoriów. Repozytorium to "baza danych" przechowująca informacje o aktualnym oraz historycznym stanie projektu. Na potrzeby początkujących można założyć że jeden projekt = jedno repozytorium. Repozytorium może być lokalne lub zdalne. Lokalne to takie które posiadasz na swoim komputerze. Zdalne, to repozytorium znajdujące się w innej lokalizacji (np. Na githubie) do którego istnieje odwołanie w repo lokalnym. Dzięki temu możliwa jest współpraca nad jednym projektem przez wiele osób.
Podstawową jednostką pracy jest commit. Jest to zapisany stan repozytorium w danym momencie. Trochę jak spakowany katalog projektu tylko bardziej inteligentny. Zdecydowana większość codziennej pracy z gitem opiera się na tworzeniu/przeglądaniu i modyfikowaniu commitów. Commit składa się z kilku elementów, m.in.:
Zmian które wprowadza
Autora
Daty utworzenia
Komentarza
Wartości hash SHA-1
Listy rodziców
Commity są unikalne rozróżnialne na podstawie hasha SHA-1. Jest on dosyć długi - w praktyce używa się jego skróconej wersji (pierwsze 6/8 znaków).
Commity mogą też dostać dodatkowe identyfikatory poza hashem - będę je nazywał etykietami. Jest kilka rodzajów etykiet. Jedna z nich to tagi. Wyobraź sobie że twój projekt osiągnął wersję 1.0 i chcesz łatwo dotrzeć do konkretnego commita zawierającego tą wersję - możesz stworzyć tag v1.0, v1.0.1 etc aby łatwo to śledzić.
Przykładowa lista commitów oraz tagów z projektu PyTorch - widać hashe, autorów, daty oraz komentarze.
Innym rodzajem tagów są tzw. gałęzie o których w tym tutorialu będzie po macoszemu (gałęzie są szerokim tematem i na początek do samodzielnej pracy nie są niezbędne).
Drzewo
Każdy commit (poza pierwszym) ma przynajmniej jednego rodzica - tzn. commit na bazie którego powstał. Tworzy to strukturę podobną do drzewa. Poniższy rysunek przedstawia dwa przykładowe drzewa. Górne jest liniowe, dolne posiada rozgałęzienie. W obu przypadkach commit A jest pierwszym (jako jedyny nie posiada rodzica). Strzałka od X do Y oznacza "X jest potomkiem Y".
Dziś skupimy się na przypadku z liniową historią, nie wszystko na raz To co muszę powiedzieć o gałęziach to, że zawsze istnieje domyślna gałąź o nazwie master. W przypadku całkowicie liniowego projektu będzie to jedyna istniejąca. Co to dla nas oznacza póki co? Ostatnio utworzony commit zawsze będzie miał dodatkową etykietę "master" co ilustruje poniższy schemat:
Nowo utworzony commit przejmuje etykietę z gałęzią rodzica (ale tylko gałęzią).
Dość teorii (na razie) - przejdźmy do praktyki.
Instalacja i konfiguracja
Będziemy potrzebowali dwóch rzeczy
Konto w serwisie GitHub - https://github.com/ - poradzisz sobie sam
Git dla Twojego systemu operacyjnego. Pokażę Ci jak go zainstalować dla systemu Windows - https://git-scm.com/downloads
Instalacja standardowo polega na klikaniu next. Większość opcji wystarczy pozostawić domyślnymi, proponuję zmienić tylko domyślny edytor tekstowy (git czasami będzie go otwierał, sugeruję wybrać notepad++ zamiast vim).
Po instalacji git będzie dostępny z każdego okna konsoli. Osobiście polecam korzystać z Git bash, który instaluje się automatycznie. Aby to zrobić kliknij PPM w dowolnym folderze i wybierz "Git Bash here". Nie ma potrzeby nic konfigurować, ja jedynie zmieniam czcionkę na większą (ppm na pasku tytułu Options/Text). Git bash emuluje podstawowe zachowanie linuksa, dlatego folder w którym jesteś zobaczysz jako np. /d/code zamiast D:\code.
(Wszystkie komendy będziemy wykonywać w oknie git bash)
Potrzebujemy ustawić dosłownie dwie opcje konfiguracyjne - nazwę użytkownika oraz email. Aby to zrobić wywołaj dwa polecenia (bez znaków ">" oznaczają one które polecenie powinieneś wpisać, linie bez tego znaku są wyjściem zwracamym przez gita):
> git config --global user.name "NAZWA UŻYTKOWNIKA"
> git config --global user.email "adres@email"
Nazwa użytkownika pojawi się przy każdym commicie razem z adresem email. Adres ustaw ten sam na który zarejestrowałeś konto na GitHub.
Polecenie git config służy do ustawiania/podglądania opcji konfiguracyjnych. Przełącznik --global oznacza, że chcemy ustawić opcję dla wszystkich repozytoriów - możliwe są różne ustawienia dla każdego repozytorium z osobna. Na końcu znajduje się opcja do ustawienia oraz jej nowa wartość.
Projekt Github
Aby uprościć nieco sprawę repozytorium załóżmy od razu na githubie. Klikamy na ikonę plusa w prawym górnym rogu i wybieramy new repository. Wpisujemy jego nazwę i zaznaczamy Initialize this repository with a README - github utworzy automatycznie pierwszy commit z readme co nam nieco ułatwi start. Po kliknięciu na Create repository repozytorium zostanie utworzone. To jest nasze zdalne repo. Musimy teraz utworzyć lokalne na jego bazie. Klikamy Clone or download, wybieramy Use HTTPS i kopiujemy URL który się pojawi.
Klonowanie repozytorium
W oknie git bash przechodzimy do folderu w którym trzymamy projekty (u mnie jest to D:/code) i wpisujemy
> git clone SKOPIOWIANY_URL
Cloning into 'git-forbot-tutorial'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 607 bytes | 3.00 KiB/s, done.
Git utworzył nowy katalog z projektem (sklonował ze zdalnego repozytorium), wejdźmy do niego (cd nazwakatalogu) u wywołajmy polecenie git status.
> git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Czytając po kolei:
Jesteśmy w gałęzi master (domyślnej)
Nasza lokalna gałąź jest aktualna względem zdalnej (origin/master)
Nie mamy żadnych zmian widocznych dla gita
Od razu warto wyjaśnić czym jest origin - jest to nazwa zdalnego repozytorium. W naszych przykładach origin będzie odnosić się do naszego zdalnego repo na githubie. Odniesienia do zdalnych repo mogą się nazywać dowolnie (i może być ich więcej) origin jest standardową konwencją.
Zobaczmy jeszcze wynik polecenia git log
> git log
commit e95e01842542a0a3a0380a34d863b906838ba1d4 (HEAD -> master, origin/master, origin/HEAD)
Author: Mateusz Bednarski <mateusz.bednarski@windowslive.com>
Date: Sat Mar 14 23:58:16 2020 +0100
Initial commit
Wyświetla ono listę commitów. Widzimy wymienione wcześniej elementy. Warto jeszcze wspomnieć czym jest HEAD - jest to etykieta oznaczająca "aktualny" commit - czyli ten który będzie rodzicem dla nowo utworzonego (po jego utworzeniu HEAD przesunie się automatycznie). Jest jeszcze origin/HEAD ale tym nie musisz się na razie przejmować.
Pierwszy commit
Najwyższa pora utworzyć pierwszy commit. Przykład będzie w zwykłym C - dla gita nie ma to absolutnie żadnego znaczenia. Tworzymy plik main.c o treści:
#include <stdio.h>
int main(){
puts("Hello world");
return 0;
}
Zapytajmy teraz gita o status repozytorium:
> git status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
main.c
nothing added to commit but untracked files present (use "git add" to track)
Pojawiły się nowe informacje. Git rozpoznał że w twoim working copy (czyli de facto tym co jest aktualnie w katalogu) pojawił się nowy plik - w stanie untracked. Stan ten oznacza, że git nie będzie się tym plikiem interesował. Aby wskazać, że nowy plik jest częścią projektu wydajemy polecenie:
> git add main.c
I jeszcze raz git status (na początku zachęcam to wydawanie tej komendy po każdej akcji - w ten sposób szybciej nauczysz się co widzi git).
> git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: main.c
Status zmienił się na staged. Co to oznacza? Plk został dodany do tak zwanego staging area albo index - jest to miejsce gdzie przygotowywany jest następny commit. W gicie tworzenie commita jest dwuetapowe - napierw dodajemy zmiany do indeksu, usuwamy je z niego, modikujemy etc - dowolnie długo do czasu kiedy nasz commit jest gotowy. Wtedy za jednym razem zapisujemy wszystkie zmiany z indeksu jako nowy commit a indeks jest czyszczony i gotowy do przygotowania następnego.
Chcemy aby nasz pierwszy commit zawierał tylko tą zmianę więc jesteśmy gotowi na:
> git commit -m "Hello world"
1 file changed, 6 insertions(+)
create mode 100644 main.c
Utworzyliśmy pierwszy commit! Jak widać służy do tego polecenie git commit. Przełącznik -m ustawia komentarz. Jeżeli go pominiesz git uruchomi edytor tekstowy gdzie będziesz mógł go wpisać. Możemy to sprawdzić wydając polecenie git log.
> git log
Kolejne commity
Idziemy za ciosem i dodajmy kolejny. Wyedytujmy plik README:
# git-forbot-tutorial
A small repository for git tutorial.
Oraz main.c
#include <stdio.h>
int main(){
puts("Hello from git-managed world!");
return 0;
}
Dodatkowo skompilujmy nasz program
gcc main.c
Jak zwykle - najpierw git status
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)
modified: README.md
modified: main.c
Untracked files:
(use "git add <file>..." to include in what will be committed)
a.exe
Widzimy, że git rozpoznał zmiany w śledzonych plikach jak również pojawienie się nowego. Dodajmy pliki źródłowe do indeksu
git add README.md main.c
(sprawdź wynik polecenia git status)
Robimy commit
git commit -m "Updated readme and hello world message"
(sprawdź git status oraz git log)
Poznaliśmy najprostszy sposób tworzenia commitów.
Ignorowanie plików
Pliku a.exe/a.out nie chcemy dodawać ponieważ jest plikiem wynikowym. W repozytorium powinny znajdować się tylko pliki źródłowe. Podobnie nie chcemy aby znalazły się tam pliki tymczasowe lub z logami. Niestety polecenie status będzie je pokazywać za każdym razem zaśmiecając nam obraz sytuacji. Oczywiście istnieje na to sposób - możemy stworzyć plik .gitignore w którym zawrzemy listę wzorców do ignorowania.
Zawartość naszego pliku .gitignore
*.exe
*.out
Istnieją generatory takich plików, doskonale nadają się na początkową wersję - np. https://www.gitignore.io/
Zobaczmy status
> git status
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
Zgodnie z tym czego oczekiwaliśmy binarka jest zignorowana. Za to plik .gitignore powinniśmy zcommitować. Zrób to sam
Wycofywanie zmian
Ok, potrafimy już dodawać zmiany. A co z ich usuwaniem? Rozpatrzymy kilka przypadków
Sceniariusz 1
Przypadkiem zmodyfikowałem plik i chcę wrócić do wersji z ostatniego commita. Kot przebiegł mi po klawiaturze i mój README wygląda teraz tak:
# git-forbot-tutorial
A small repository for git tutorial.
asdhawgdagwdkaw
> git status
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)
modified: README.md
Aby wrócić do wersji z ostatniego commita wykonaj
> git restore README.md
To wszystko
UWAGA: git restore jest dosyć nowym poleceniem (przez co jeszcze mało popularnym). Inną metodą jest
> git checkout -- README.md
Secnariusz 2
Dodałem zmiany do indeksu ale jednak nie chcę ich commitować, co robić?
Wprowadźmy zmiany do pliku main.c
#include <stdio.h>
int main(int argc, char** argv){
puts("Hello from git-managed world!");
puts("I can handle args");
return 0;
}
I dodajemy je do staging area
> git add main.c
(o git status już nie będę wspominał)
Niestety zaszła pomyłka i nowy commit miał wyglądać tak:
#include <stdio.h>
int main(int argc, char **argv){
puts("Hello from git-managed world!");
puts("I can handle args");
return 0;
}
Nie ma problemu! Popraw plik i zobaczmy co pokaże status
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: main.c
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)
modified: main.c
Widać, że plik main.c pojawił się zarówno w staging area jak i jako not staged - interpretacja jest prosta - część zmian została dodana do indeksu a część nie. Jeżeli teraz wykonamy commit to znajdą się tam tylko poprzednio dodane zmiany. My jednak teraz chcemy dodać poprawki, wykonaj git add main.c i sprawdź status a następnie wykonaj commit.
Scenariusz 3
A co jeśli nie chcemy poprawiać zmian tylko po prostu je wycofać ze staging area? Wystarczy wykonać
> git restore --staged
zmiany zostaną wycofane z indeksu ale pozostaną w kopii roboczej. Na przykład:
# Modyfikujuemy plik README
> git add README.md
> git status (przeanalizuj)
> git restore --staged
> git status (przeanalizuj i sprawdź zawartosc pliku README)
IMG
Teraz jest dobry moment na pauzę i przećwiczenie samodzielnie powyższych poleceń
Usuwanie plików
No dobrze, a co jeżeli chcę usunąć plik z repozytorium? Na początek dodajmy nowy plik (może być pusty)
> git add info.txt
> git commit info.txt -m "Added info"
Wydaj polecenie rm info.txt (lub usuń plik z poziomu IDE, wychodzi na to samo) i sprawdź status
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: info.txt
Git zarejestrował usunięcie pliku, teraz wystarczy git add info.txt i git commit
Uwaga: istnieje również polecenie git rm które pozwala na usuwanie plików z repozytorium i pozostawienie ich w kopii roboczej. Jest to nieco bardziej zaawansowany temat i teraz go pominę.
Tworzenie tagów
Wspominałem, że git pozwala dopasowywać dodatkowe etykiety do commitów. Zróbmy to teraz - przyda się za chwilę. Wydaj polecenie git log, wybierz dowolny commit i skopiuj pierwsze 6 znaków jego SHA-1. Następnie wywołaj
> git tag -a -m "Version 1.0" v1.0 WYBRANE_SHA
Przełącznik -a tworzy tzw "annotated tag" - który zawiera autora, komentarz (dodany przełącznikiem -m). v1.0 to nazwa tagu, na końcu znajduje się hash commita do otagowania. Jeżeli pominiesz ten ostatni, git wybierze aktualny (ten gdzie wskazuje HEAD, ale o tym jeszcze za chwilę).
Wykonaj git log aby zobaczyć swój tag
[...]
commit 6146854e0e8545bbbd5968f29a805d1c728e73a0 (tag: v1.0)
[...]
Istnieją również "lightweight tag" które zawierają tylko nazwę taga (bez przełączników -a i -m). Ja generalnie rekomenduję użycie tagów zanotowanych - ze względu na większą ilość informacji, lekkich używam tylko do tagów tymczasowych.
Przeglądanie historii
Na początku mówiłem, że git pozwoli Ci cofać się w czasie - zobaczmy jak to działa. Załóżmy, że chcesz wrócić do konkretnego stanu repozytorium. Zacznijmy od tego otagowanego. Na początek upewnij się że zarówno working copy jak i indeks są czyste - nie jest to wymagane ale będzie ułatwieniem.
Aby przejść do historycznej wersji kodu wpisz
> git checkout v1.0
Gdzie zamiast v1.0 może być dowolny istniejący tag lub ID commita.
Git wypluwa dość długi komunikat - w skrócie repozytorium jest w stanie detached HEAD. Oznacza to, że nie jesteś w żadnej gałęzi. Na tym etapie rekomenduję uznać że taki stan oznacza "nie rób żadnych zmian w kodzie ktore mozesz chcieć zachować" - o tym jak to dokładnie obsłużyć będzie w drugiej części poświęconej gałęziom.
To co nas w tej chwili interesuje to fakt "HEAD is now at 6146854 Added .gitignore" - w kopii roboczej znajduje się wersja kodu z tego konkretnego commita i HEAD (czyli wskaźnik "aktualnego" commita) jest tutaj ustawiony. Możesz np. sprawdzić jakie są różnice w pliku main.c względem najnowszego
> git diff HEAD master main.c
Czyli "pokaż mi różnicę między commitami HEAD oraz master w pliku main.c". Wiesz co oznacza HEAD, przypomnę że master jest etykietą najnowszego commita w gałęzi master. Git diff ma dużo więcej możliwości, zachęcam do zapoznania się z dokumentacją.
Ok, zrobiliśmy inspekcję i chcemy wrócić do mastera. Co zrobić? Wystarczy wywołać
> git checkout master
Wrócimy do naszej gałęzi, HEAD zostanie również odpowiednio ustawiony.
Przywracanie plików w wersji historycznej
Załóżmy, że znalazłeś w którym miejscu historii wprowadziłeś błąd i chcesz przywrócić historyczną wersję pliku. Wystarczy wykonać
> git checkout ID_COMMITA nazwa_pliku
Czyli "przywróć plik nazwa_pliku z commita o id ID_COMMITA" gdzie id może być skrócony hash lub tag. Zmiana od razu wyląduje w staging area.
(o wykonywaniu git status nie muszę przypominać )
Podsumowanie (niektórych) operacji
Synchronizacja ze zdalnym repozytorium
Kiedy wejdziesz na swoje repozytorium na githubie zobaczysz że nic się nie zmieniło - taka jest idea gita - system jest rozproszony i wszystkie zmiany dzieją się lokalnie. Aby przekazać swoje zmiany do zdalnego repozytorium wydaj polecenie:
> git push
Git poprosi Cię o zalogowanie się. Po pomyślnym wykonaniu polecenia odśwież stronę i zobaczysz swoje zmiany. Istnieje również możliwość pracy bez podawania hasła, przy użyciu klucza SSH.
Dobre praktyki
Git jak każde narzędzie zaawansowane narzędzie pokazuje pełnię mocy jeśli jest używany poprawnie. Wymaga to nieco doświadczenia ale jest kilka dobrych praktyk, które mozesz wdrożyć od razu:
Wiadomości w commitach powinne być dokładne
Jeden commit = jedna zmiana (w sensie logicznym, jak najbardziej może to być wiele plików)
Staraj trzymać się working copy czyste, sytuacja kiedy przed tygodnie masz untracked files i nie dodałeś ich do gitignore "bo później się przydadzą" to proszenie się o kłopoty
Commituj często - ja w pracy zwykle robię ok. 10 commitów dziennie
Często używaj poleceń log oraz status
Zanim zaczniesz używać gita w swojej pracy magisterskiej nabierz nieco doświadczenia na mniejszym projekcie
Wypróbuj narzędzie gitk do graficznego przeglądania drzewa
Nie rekomenduję używania narzędzi do obsługi gita wbudowanych w IDE - często robią one więcej niż sugerują nazwy poleceń
Git miejscami jest mało intuicyjny, nie zrażaj się że czegoś od razu nie rozumiesz.
Interfejs programu gitk
Zakończenie części pierwszej
Ufff, spro informacji jak na jeden raz. Jeżeli mój styl pisania się Wam spodoba to przygotuję drugą część gdzie opiszę dokładniej jak pracować ze zdalnym repozytorium oraz gałęziami.
Niemniej posiadasz już podstawową wiedzę, która pozwoli Ci korzystać z dobrodziejstw Gita.
Powodzenia
