GIT poradnik22.XI.2014

Spis treści

  1. Instalacja
  2. Wstępna konfiguracja
  3. Ułatwienie na zakończenie
  4. Najczęsciej używane / często zapominane
  5. Referencje

Instalacja

Tu w zasadzie nie ma co wyjaśniać. Wystarczy znaleźć w ulubionej wyszukiwarce stronę z instalajcą GITa i zainstlować. Aktualnie instalacja znajduje się pod adresem http://git-scm.com/downloads.

Wstępna konfiguracja

GITa można wstępnie skonfigurować tak, aby podczas każdej publikacji przesyłał prawidłowe informacje o autorze zmian. Co więcej można zdefiniować aliasy, które znacznie przyspieszą wykonywanie częstych operacji w GITcie. 

\> git config --global user.name "John Doe"
\> git config --global user.email johndoe@example.com
\> git config --global alias.co checkout
\> git config --global alias.st status

Ułatwienie na zakończenie

Zanim umieszczę listę najbardziej przydatnych dla mnie poleceń należy zwrócić uwagę na pewien problem, który jest dość irytujący przy pracy z jakimkolwiek repozytorium zdalnym np. GitHubem. Scenariusz jest prosty i pewnie często spotykany. Czyli mamy założone co najmniej dwa repozytoria na GitHubie i dla każdego z nich mamy włączoną publikację za pomocą klucza SSH.

Problem polega jednak na tym, że GitHub pozwala na dodanie tego samego klucza publikacji tylko do jednego repozytorium. Jak uporać się zatem z tym problem w sytuacji gdy klucz SSH jest zapamiętywany per nazwa hosta? Odpowiedź poniżej.

  1. Przygotowujemy klucz publikacji (deploy key) za pomocą polecenia 
    \> ssh-keygen
    domyślnie będą to pliki "id_rsa" i "id_rsa.pub" (odpowiednio klucz prywatny i publiczny)
  2. Zmieniamy nazwę wygenerowanych kluczy (prywatnego i publicznego), które znajdują się w katalogu ".ssh" profilu, tak aby zawierały nazwę repozytorium lub dowolnie inaczej jak chcemy aby łatwo było poznać do czego dana para kluczy służy
    • id_rsa.test
    • id_rsa.test.pub
  3. Dodajemy do pliku konfiguracyjnego SSH (~/.ssh/config) konfigurację dla "nowego hosta"/"aliasu hosta" pod jakim będzie następowała komunikacja z repozytorium. U mnie wygląda to tak: 
    # account for the test repo
Host github.com-test
    HostName github.com
    User pieszynski
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_rsa.test
  4. Teraz należy dodać swój klucz publiczny (zawartość pliku id_rsa.pub bez końcowej nazwy komputera) do repozytorium na github.com w sekcji "Deploy keys". Jeśli tego nie zrobimy to w konsoli pojawi się komunikat (przy klonowaniu przez SSH): 
    Cloning into 'test'...
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
  5. Klonujemy repozytorim za pomocą SSH a nie HTTPS (choć GitHub domyślnie podaje adres HTTPS)! Oraz nazwa hosta, podawana przez GitHub musi być zmieniona na taką jaka została wpisana w konfiguracji "Host". 
    \> git clone git@github.com-test:pieszynski/test.git
  6. Jeśli już repozytorium posiada źle ustawiony "remote" można to skorygować za pomocą: 
    \> git remote -v
# kopiujemy sobie adres aby go zmienić
\> git remote rm origin
\> git remote add origin nowy_remote
\> git remote -v

Najczęsciej używane / często zapominane

# róznego rodzaju konfiguracje .gitignore
https://github.com/github/gitignore

# odtworzenie repozytorium lokalnie
git clone git://github.com/schacon/grit.git

# dodanie do poprzedniego commit zapomnianych zmian 
#   (żeby wsztstko było w jednym COMMIT a nie kilku)
git commit --amend

# publikacja zmian na serwer zdalny
git push origin master

# otagowanie
git tag -a "v1.0" -m"cookie version 1.0"

# przesłanie taga na serwer zewnętrzny (automatycznie tagi się nie przenoszą)
git push origin "v1.0"

# przełączenie na inny BRANCH
git checkout nazwa_branch

# stworzenie nowego czystego BRANCH z aktualnego
git checkout -b nowa_nazwa

# zintegrowanie do AKTUALNEGO branch ten, który został podany jako parametr
git merge nazwa_branch

# usunięcie istniejącej gałęzi
git branch -d nazwa_branch

# przeniesienie pliku i dodanie tej operacji do STAGE
git mv

# usunięcie pliku z repozytorium i dodanie tej operacji do STAGE
git rm

# ustawienie statusu do skasowania jak jest już w STAGE
git rm --cached

# przywrócenie wszystkich plików zakwalifikowanych do STAGE
git reset .

# przywrócenie wszystkich plików do takich z ostatniego z COMMIT
git checkout .

# odtworzenie pliku z innego brancha
git checkout source_branch <paths>

# wylistowanie zmian
git diff

# wylistowanie zmian do wprowadzenia z STAGE do COMMIT
git diff --cached

# wylistowanie historii COMMITów z wprowadzonymi zmianami
git log -p

# wylistowanie historii dwóch COMMITów z wprowadzonymi zmianami
git log -p -2

# wylistowanie statystyk zmian w COMMITach
git log --stat

# wylistowanie graf COMMITów i BRANCHy
git log --graph

# aktualizacja repozytorium będącego FORKiem oryginalnego
git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
git fetch upstream
git checkout master
git merge upstream/master
git push origin master

Referencje