Repository navigation
Czym jest GIT
#Czym jest GIT?
GIT jest rozproszonym systemem kontroli wersji. Pozwala m.in. śledzić zmiany wprowadzone w poszczególnych plikach projektu oraz prowadzić prace nad projektem równolegle dowolnej ilości osób poprzez zestaw rozbudowanych funkcjonalności.
W niniejszym projekcie skupimy się na niezbędnych podstawach pracy z repozytorium GIT.
GIT jest systemem rozproszonym, oznacza to, że każdy programista przechowuje u siebie niezależną kopię plików. Wprowadzone do projektu zmiany należy samodzielnie synchronizować. Zmiany śledzone są w obrębie gałęzi (ang. branch), przy czym na potrzeby naszego projektu najpewniej będziemy wykorzystywać tylko jedną o domyślnej nazwie "master".
Repozytorium przechowuje tylko różnice (ang. differences - diffs - diff) między kolejnymi pakietami zmian na każdej z gałęzi. Każdy pakiet zmian nazywamy commitem, tworzymy go samodzielnie.
Kluczowe informacje: branch, commit, diff.
Nie wszystkie pliki w naszych katalogach roboczych są istotne dla GITa, nie wszystkie też za każdym razem modyfikujemy. Czasem potrzebujemy również zmodyfikować plik, ale nie wysyłać go do repozytorium np. podczas ustawiania danych do naszej bazy danych w plikach konfiguracyjnych. Aby obsłużyć wszystkie scenariusze, GIT wprowadza garś różnych stanów, w jakich mogą znajdować się pliki. Przedstawię tutaj najważniejsze dla tego projektu.
-
ignorowane - pliki, które git będzie celowo omijał. Reguły dla nich definiowane są w pliku
.gitignore. Są to najczęściej pliki binarne wygenerowane w procesie kompilacji lub pobrane z menedżera pakietów NuGet. - nieśledzone - pliki, które aktualnie w ogóle nie są uwzględniane przez repozytorium. Mogą to być po prostu pliki nowe lub usunięte z repozytorium, ale nie katalogu roboczego. Podczas pracy z VS będzie on dbał o to, by nowe pliki były automatycznie dodawane do repozytorium.
- śledzone niezmodyfikowane - jak nazwa wskazuje, są w repo, ale nie wprowadzono w nich żadnych zmian od ostatniego commita
- śledzone zmodyfikowane - jak wyżej, ale wprowadzono zmiany. UWAGA: to jeszcze nie znaczy, że znajdą się w następnym pakiecie zmian :)
- zmodyfikowane do wysłania - jak wyżej, z tym, że różnice względem poprzedniego commita będą zapisane przy następnym commicie
Każda lokalna kopia repozytorium może mieć własny zestaw gałęzi, commitów itp. Ręcznie wywołujemy akcje wysyłające/pobierające zmiany ze zbiorów zdalnych (zewnętrznych - ang. remote). Podczas klonowania (pobierania np. z githuba) repozytorium za pomocą wbudowanych w klient GITa narzędzi, automatycznie ustawiane jest odwołanie do repozytorium źródłowego (origin) oraz gałąź master jako bezpośredni odpowiednik gałęzi origin/master. Od tego momentu możemy użyć akcji:
- commit - zapisz nowy pakiet zmian w aktywnej gałęzi
- push - wyślij wszystkie niewysłane lokalne commity do origin
- pull - pobierz wszystkie nowe commity na origin i spróbuj połączyć je z lokalnymi (innymi słowy, zaktualizuj aktywną gałąź)
- fetch - pobierz nowe commity, ale nic z tym jeszcze nie rób
W następnych wpisach na wiki przedstawię jak to robić za pomocą Tortoise GIT i VS 2015.
Podczas równoległej pracy nad repozytorium może zdażyć się sytuacja, w której dwie osoby zmodyfikują np. tą samą linijkę w tym samym pliku na dwa różne sposoby. W takim przypadku zarówno GIT nie poradzi sobie sam, należą (ang. merge) połączyć te zmiany specjalnym commitem łączącym.
Jest to na tyle złożone zagadnienie, że będzie omówione na jednym ze spotkań kursowych. Opis być może pojawi się w późniejszym czasie.
W następnych wpisach poruszone zostaną tematy:
- równologłej pracy w serwisie Github (forki i pull requesty) - Github
- pracy z programem Tortoise GIT - Tortoise GIT
- pracy z repozytorium w Visual Studio 2015