Ten wpis jest podsumowaniem wiedzy, którą zdobywałem czytając wprowadzenie do gita na stronie gitref.org. Jest to w zasadzie kurs który można tam przeczytać, tyle że przetłumaczony na język polski.
Instalowanie kluczy zostało praktycznie przeklejone ze strony eastgroup.pl. Wszelkie uwagi do tłumaczenia, błędów w skrypcie, uwag stylistycznych, merytorycznych i innych złośliwości należą się mnie, brawa i słowa gratulacji oryginalnym twórcom kursu.
O tym czym jest git można przeczytać na pl.wikipedia.org. Aby móc skorzystać z poleceń, które są tutaj wymieniane należy zainstalować gita, można go pobrać z strony http://git-scm.com/ klikając w odpowiedni system operacyjny. Ja skorzystałem z Git-1.7.4-preview20110204.exe dla windows.
Do dzieła!

Git podstawy:

• Tworzenie repozytorium git w aktualnym katalogu: git init
• Klon repozytorium ze zdalnego URL git clone url, wszystkie informacje na temat repozytorium zostają sklonowane. Git utworzy nowy katalog o nazwie projektu z którego został stworzony klon. Lokalna kopia posiada pełną historię zmian.
• Status plików w aktualnym katalogu git status (-s krótszy opis). Wynikiem takiej operacji będzie lista plików z przypisanymi do nich atrybutami, poniżej znaczenie tych atrybutów:
  ? – nie zawierają się w repo
  A – dodany
  M -zmodyfikowany
  D – plik usunięty
  U – plik zaktualizowany ale nie zmerdżowany
  C – plik skopiowany
  R – plik przeniesiony
  Jeżeli nic nie zostanie wyświetlone, oznacza to że żadnej z plików nie został zmodyfikowany, a więc nie ma w ogóle o czym mówić. Krótki status (-s) zawiera informacje o plikach podzieloną na dwie kolumny; 1- wartość względem lokalnego repozytorium, 2- wartość dla aktualnie wprowadzanych zmian. Warto wspomnieć, że plik zmodyfikowany ale nie dodany do tworzonego snapshota nie będzie wykorzystany w trakcie wykonywania polecenia git commit (o tym rozkazie niżej). Status takiego pliku to ? albo M.
• Dodanie nowych plików do snapshota lub zatwierdzanie zmian w plikach, dla których już jest prowadzony index w repozytorium to git add filename, można podać więcej niż jeden plik jako parametr. Dodanie wszystkich plików z aktualnego katalogu git add *. Dodanie wszystkich plików i wszystkich podkatalogów git add .(to jest kropka jako parametr).
• Sprawdzenie aktualnych zmian wprowadzonych lokalnych plikach  git diff. 
• Zmiany snapshot względem repozytorium to git diff –cached.
  Istnieje także opcja pominięcia snapshota i sprawdzenie zmian względem repozytorium, takim poleceniem git diff HEAD.
  Podsumowanie zmian, które zostały wprowadzone w plikach, ale bez szczegółów dotyczących tych zmian git diff –stat.
• Wysłanie snapshota, w snapshot znajdą się tylko pliki zatwierdzone poleceniem git add (czyli posiadają status A), do repozytorium: wykonać polecenie git commit -m commenthere i snapshot zostaje zapisany do lokalnego repozytorium. Poleceni git commit potrafi także skorzystać z plików, które nie zostały dodane do snapshota, należy skorzystać z przełącznika a, wykonać git commit -am commenthere (uwaga: chyba nie działa na branchach).
  Pominięcie parametru m spowoduje, że git otworzy w domyślnym edytorze plików plik (coś mi się wydaje, że jednak zawsze jest to vim – INSERT, napisz komentarz, ESC, :wq, ENTER), gdzie należy podać komentarz do aktualnie tworzonego commita.
  Należy, a w zasadzie trzeba! podczas comitowania podawać opis wprowadzanych zmian – taka dygresja.
• Jeżeli będzie potrzeba cofnąć plik ze stanu A do M (z jakiegoś powodu, nie chcemy zapisywać zmian), należy użyć polecenia git reset HEAD — filename (po — jest spacja), po takiej operacji zawartość pliku nie zostanie zmieniona, ale zostanie on uznany za lokalnie nie zatwierdzony, co spowoduje jego domyślne pominięcie przy wykonaniu operacji git commit.
  Git rozróżnia kolejność parametrów, poleceni git commit –am nie jest równe git commit –ma – warto o tym pamiętać.
• Usunięcie pliku z repozytorium oraz z dysku git rm filename, jeżeli z jakiegoś powodu plik należy usunąć tylko z git, ale pozostawić go na dysku warto dodać parametr cached, polecenie wyglądać będzie tak git rm –cached filename. Równie dobrze można po prostu usunąć plik samodzielnie z katalogu, a następnie potwierdzić zmiany poprzez git add.. 

Tworzenie nowych gałęzi dla projektu oraz ich łączenie (merge)
Czasem pojawia się potrzeba zrobienia czegoś na boku, w gitcie możemy to osiągnąć za pomocą polecenia git branch oraz git checkout.

• git branch wyświetli listę wszystkich dostępnych rozgałęzień w projekcie, gdy poda się nazwę nowej gałęzi zostanie ona utworzona: git branch nowy. Wywołanie git branch -d nazwa spowoduje jej usunięcie. Warunkiem jest to, że zmiany zostały już zaakceptowane oraz połączone z główną gałęzią lub ich nie wprowadzono. Można także wymusić usunięcie poprzez krzyknięcie, czyli -D. 
• Po stworzeniu gałęzi, aby na niej pracować należy się na nią przełączyć, służy do tego polecenie git checkout nazwa, od tej pory pracujemy na nowej gałęzi projektu, wszelkie zmiany będą widoczne tylko gdy będzie ona aktywna. Dla leniwych istenieje polecenie git checkout -b nazwa, który tworzy nowy gałąź i automatycznie się na nią przełącza.

Pracując na boku korzysta się oczywiście z poleceń git add i git commit, a po wszystkim gdy trzeba połączyć gałęzie z pomocą przychodzi git merge nazwa. Git scala obie gałęzie projektowe, wraz z historiami obu. Oczywiście może pojawić się konfilikt podczas tej operacji, użytkownik zostanie o tym poinformowany plik zostaną złączone a odpowiednie wstawki z narzędzia merdżującego znajdą sie w plikach (>>>>> oraz <<<<<). Po wywołaniu git status -s pliki, które są w konfilikcie i wymagają ingerencji programisty będą miec status U, należy wtedy ręcznie dokonać operacji łączenia plików, oraz zaakceptować wynik poprzez git add plik a następnie git commit -m pamiętając o komentarzu.

• Dla wścibskich historyków powstało polecenie git log wyświetlające historię comitów do repo. Warto sprawdzić użycie przełączników git log [–oneline] [–graph] [–decorate]. Można stosować je razem i osobno, kwestia gustu. 
• Wspierane są także labelki (tag) git tag -a nazwa_labelki.

Praca ze zdalnym repozytorium
Wszystkie operacja, które zostały do tej pory opisany, miały charakter lokalny. Nikt nie miał do nich dostępu, źródła było tworzone i modyfikowane wyłącznie osoby korzystające z tego komputera. Czas więc udostępnić nasze poprawki i złote myśli innym, niech podziwiają naszą wiedzę i kunszt programistyczny. Aby tego dokonać potrzeba będzie postawić server git, a tym zdecydowanie kiedy indziej. Zakładam że skorzysta się z dostępnych gdzieś serwerów np. github.com i sklonuje sie repozytorium do siebie na dysk.
Oto link do mojego przykładowego repozytorium, które zawierać powinno plik c, c++, czy c# wyświetlające hello world. Także można z niego śmiało skorzystać, aby zrobić klona git://github.com/jsthedeveloper/hello-world-blog-example.git

• Sklonowanie projektu do siebie na dysk uzyskuje się za pomocą polecenia git clone url, gdzie url to zdalna ścieżka do repozytorium z którego chcemy skorzystać. Taka sklonowana wersja zawiera całą historię projektu, można ją obejrzeć za pomocą git log –oneline –graph –decorate (:q).
• Wyświetlenie serwerów (aliasów) z których korzysta sklonowane repozytorium to git remote (parametr -v poda dokładne adresy). Dodanie nowego serwera to git remote add [alias] [url] i oczywiście usunięcie git remote rm alias
• Gdy zaistnieje potrzeba aktualizacji lokalnych źródeł do najnowszych dostępnych na zdalnych repozytoriach można skorzystać z opcji git fetch [alias], jeżeli korzysta sie z więcej niż jednego serwera. Po takiej operacji może wystąpić potrzeba merga git merge. Git lubi leniwców, istnieje więc poleceni git pull, które jest połączeniem git fetch i git merge.
• Potem następuje normalna praca (add/commit), jeżeli chce się wysłać zmiany na zdalne repozytorium należy użyć polecenia git push [alias] [branch]. Aby móc poprawnie wykonać pusha, należy się poprawie autoryzować w repo i mieć uprawnienia do zapisu w repo, co przekłada sie na posiadanie odpowiedniego linka do repo.

Generowanie kluczy
Jeżeli nie posiadamy kluczy rsa, możemy skorzystać z pomocy git-basha, który został zainstalowany na naszym komputerze, do wygenerowania odpowiedniej pary kluczy [RSA wikipedia]. Uruchamiamy Git Bash następnie wykonujemy poleceni ssh-keygen i idąc po najmniejszej linii opory na wszystko odpowiadamy enterem. Bash napisze gdzie zostały zapisane klucze, zawartość pliku z kluczem publicznym przeklejamy do serwera gitowskiego i od tej pory git push powienien działać.
To by było w sumie na tyle, jeśli chodzi o git w konsoli. Istnieją graficzne nakładki na git, jeżeli do instalacji został wykorzystany link, który podałem, to można od razu skorzystać z opcji git gui. Ten wpis jednak nie będzie tego omawiać.
Jeżeli po przeczytaniu będą pytania, proszę o kontakt. Jeżeli po przeczytaniu będą nudności, proszę załatwić sobie radyjko. Innego typu uwagi, proszę komentarz, mail, czy inna forme komunikacji.

JS