GIT - system kontroli wersji

System kontroli wersji (VCS-Version Control System) śledzi wszystkie zmiany dokonywane na pliku (lub plikach) i umożliwia przywołanie dowolnej wcześniejszej wersji. 

Git – rozproszony system kontroli wersji
Git stanowi wolne oprogramowanie i został opublikowany na licencji GNU GPL w wersji 2.
Najważniejsze cechy:
- Dobre wsparcie dla rozgałęzionego procesu tworzenia oprogramowania.
- Praca off-line
- Wsparcie dla istniejących protokołów sieciowych: HTTP(S), FTP, rsync, SSH.
- Efektywna praca z dużymi projektami
- Każda rewizja to obraz całego projektu: zapamiętuje kompletne obrazy.

Git server
Jako rozproszony system kontroli wersji, Git nie wymaga odrębnej aplikacji serwerowej. Istnieją jednak pakiety rozszerzające oryginalne oprogramowanie, przede wszystkim o kontrolę dostępu, wsparcie dla zarządzania wieloma repozytoriami, czy interfejs WWW. Przykłady niektórych popularnych projektów to Git Daemon, Gitolite, Gerrit, Gitiles, Bonobo, Git Server.

Hosting
Istnieje kilka serwisów hostingowych umożliwiających trzymanie repozytoriów gita, m.in GitHub, Bitbucket, Gitorious i Stash.

Rozproszony system kontroli wersji
(DVCS - Distributed Version Control System)
W systemach DVCS (takich jak Git, Mercurial, Bazaar lub Darcs) klienci nie dostają dostępu jedynie do najnowszych wersji plików ale w pełni kopiują całe repozytorium. Gdy jeden z serwerów, używanych przez te systemy do współpracy, ulegnie awarii, repozytorium każdego klienta może zostać po prostu skopiowane na ten serwer w celu przywrócenia go do pracy

Sposób przechowywania danych
Git traktuje dane jak zestaw migawek (ang. snapshots) małego systemu plików. Za każdym razem jak tworzysz commit lub zapisujesz stan projektu, Git tworzy obraz przedstawiający to jak wyglądają wszystkie pliki w danym momencie i przechowuje referencję do tej migawki. W celu uzyskania dobrej wydajności, jeśli dany plik nie został zmieniony, Git nie zapisuje ponownie tego pliku, a tylko referencję do jego poprzedniej, identycznej wersji, która jest już zapisana.

Lokalizacja plików
Większość operacji w Git do działania wymaga jedynie dostępu do lokalnych plików i zasobów – nie są potrzebne żadne dane przechowywane na innym komputerze w sieci.
Oznacza to, że można zrobić prawie wszystko będąc poza zasięgiem sieci lub firmowego VPNa.

Mechanizm spójności danych
Dla każdego obiektu Git wyliczana jest suma kontrolna przed jego zapisem i na podstawie tej sumy można od tej pory odwoływać się do danego obiektu. Oznacza to, że nie ma możliwości zmiany zawartości żadnego pliku, czy katalogu bez reakcji ze strony Git.
Mechanizmem, który wykorzystuje Git do wyznaczenia sumy kontrolnej jest tzw. skrót SHA-1. Jest to 40-znakowy łańcuch składający się z liczb szesnastkowych (0–9 oraz a–f), wyliczany na podstawie zawartości pliku lub struktury katalogu.

Git przechowuje wszystko nie pod postacią plików i ich nazw, ale we własnej bazie danych, w której kluczami są skróty SHA-1, a wartościami - zawartości plików, czy struktur katalogów.

Rejestrowanie zmian w repozytorium
Git posiada trzy stany, w których mogą znajdować się pliki: zatwierdzony, zmodyfikowany i śledzony.

Zatwierdzony	oznacza, że dane zostały bezpiecznie zachowane w Twojej lokalnej bazie danych.
Zmodyfikowany	oznacza, że plik został zmieniony, ale zmiany nie zostały wprowadzone do bazy danych.
Śledzony	oznacza, że zmodyfikowany plik został przeznaczony do zatwierdzenia w bieżącej postaci w następnej operacji commit.

Każdy plik w twoim katalogu roboczym może być w jednym z dwóch stanów: śledzony lub nieśledzony.
Śledzone pliki to te, które znalazły się w ostatniej migawce; mogą być niezmodyfikowane, zmodyfikowane lub oczekiwać w poczekalni. Nieśledzone pliki to cała reszta — są to jakiekolwiek pliki w twoim katalogu roboczym, które nie znalazły się w ostatniej migawce i nie znajdują się w poczekalni, gotowe do zatwierdzenia.

Początkowo, kiedy klonujesz repozytorium, wszystkie twoje pliki będą śledzone i niezmodyfikowane, ponieważ dopiero co zostały wybrane i nie zmieniałeś jeszcze niczego.
Kiedy zmieniasz pliki, Git rozpoznaje je jako zmodyfikowane, ponieważ różnią się od ostatniej zatwierdzonej zmiany. Zmodyfikowane pliki umieszczasz w poczekalni, a następnie zatwierdzasz oczekujące tam zmiany i tak powtarza się cały cykl.

Katalogi
Z powyższego wynikają trzy główne sekcje projektu Git: katalog Git, katalog roboczy i przechowalnia (ang. staging area).

Katalog roboczy (working directory)
Stanowi obraz jednej wersji projektu. Zawartość tego katalogu pobierana jest ze skompresowanej bazy danych zawartej w katalogu Git i umieszczana na dysku w miejscu, w którym można ją odczytać lub zmodyfikować.

Przechowalnia (staging area)
To prosty plik, zwykle przechowywany w katalogu Git, który zawiera informacje o tym, czego dotyczyć będzie następna operacja commit. Czasami można spotkać się z określeniem indeks, ale ostatnio przyjęło się odwoływać do niego właśnie jako przechowalnia.
 
Katalog Git (git directory)
Jest miejscem, w którym Git przechowuje własne metadane oraz obiektową bazę danych Twojego projektu. To najważniejsza część Git i to właśnie ten katalog jest kopiowany podczas klonowania repozytorium z innego komputera.

Podstawowy sposób pracy z Git wygląda mniej więcej tak:

1. Dokonujesz modyfikacji plików w katalogu roboczym.
2. Oznaczasz zmodyfikowane pliki jako śledzone, dodając ich bieżący stan (migawkę) do przechowalni.
3. Dokonujesz zatwierdzenia (commit), podczas którego zawartość plików z przechowalni zapisywana jest jako migawka projektu w katalogu Git.

Jeśli jakaś wersja pliku znajduje się w katalogu git, uznaje się ją jako zatwierdzoną.
Jeśli plik jest zmodyfikowany, ale został dodany do przechowalni, plik jest śledzony.
Jeśli zaś plik jest zmodyfikowany od czasu ostatniego pobrania, ale nie został dodany do przechowalni, plik jest w stanie zmodyfikowanym.


Git bare repository
Zdalne repozytorium to nic innego jak samo repozytorium bez kopii roboczej (ang. bare repository). Ponieważ repozytorium to jest wykorzystywane wyłącznie jako miejsce współpracy, nie ma potrzeby by na dysku istniała migawka jakiejkolwiek wersji; to po prostu dane Git. Mówiąc krótko - takie repozytorium to wyłącznie zawartość katalogu .git.

Download GIT
https://git-scm.com/download/win

Przygotowanie zdalnego (centralnego) bazowego repozytorium
1. Zainstaluj GIT używając domyślnych ustawień
2. Utwórz katalog repozytorium (np. C:\GitRepo) i dodaj do niego foldery i pliki, które chcesz przechowywać w repozytorium
3. Uruchom konsolę GIT (C:\Program Files\Git\git-bash.exe)
- wpisując w konsoli
                                                      cd c:/GitRepo
  przejdź do katalogu repozytorium
- utwórz bazowe repozytorium wpisując
                                                       git init --bare

Tak wygląda utworzony katalog repozytorium zdalnego:

Klonowanie repozytorium
1. Utwórz katalog gdzie chcesz sklonować repozytorium (np. c:/GitRepoClone )
1. Uruchom konsolę GIT
2. Sklonuj repozytorium 
                                             git clone c:/GitRepo C:/GitRepoClone
https://git-scm.com/docs/git-clone
- aby z niego korzystać wejdź do katalogu docelowego
                                                       cd C:/GitRepoClone

Wrzucanie plików do repozytorium centralnego
1. Tworzymy foldery i pliki w katalogu C:/GitRepoClone
- komenda
                                                       git status
  https://git-scm.com/docs/git-status
  wskazuje, że w katalogu repozytorium znajdują się nieśledzone foldery
2. Dodaj foldery i pliki do repozytorium
                                                       git add .
  https://git-scm.com/docs/git-add
3. Zatwierdź zmiany
                                                       git commit -m "Commit text"
  https://git-scm.com/docs/git-commithttps://git-scm.com/docs/git-commit
4. "Wypchnięcie" zmian do repozytorium centralnego
                                                       git push
https://git-scm.com/docs/git-push

Git:

Oto jak wygląda ta sytuacja w programie SourceTree:

Wrzucanie zmian do repozytorium centralnego
1. Dokonujemy zmian w naszym sklonowanym repozytorium
- Modyfikujemy "Plik1.txt"
- Usuwamy "Plik2.txt"
- Zmieniamy nazwę "Plik3.txt" -> "Plik3Rename.txt"
- Dodajemy "Plik4.txt"
- Oto jak to wygląda w SourceTree:

- sprawdzamy status repozytorium
                                                       git status
  widać, na których plikach dokonano zmian.
2. Dodajemy zmiany do repozytorium
                                                       git add .
- Oto jak to wygląda w SourceTree:

3. Zatwierdź zmiany
                                                       git commit -m "Commit text"
- Oto jak to wygląda w SourceTree:

4. "Wypchnięcie" zmian do repozytorium centralnego
                                                       git push
- Oto jak to wygląda w SourceTree:

Jak to wygląda w GIT:

C.D.N. ...


http://www.mimuw.edu.pl/~lukaszcz/git.html
https://git-scm.com/book/pl/v1
https://pl.wikipedia.org/wiki/Git_(oprogramowanie)
https://git-scm.com/book/pl/v1/Pierwsze-kroki-Wprowadzenie-do-kontroli-wersji
http://marioosh.5dots.pl/2009/08/20/praca-ze-zdolnym-repozytorium-w-git.html
http://osworld.pl/dobre-praktyki-w-gitcie-czyli-zbior-zasad-w-pracy-zespolowej-przydatnych-trickow-najczesciej-wykorzystywanych-komend/

http://overapi.com/git
http://justinhileman.info/article/git-pretty/