Git/Przypadki

Wcześniej musimy ustalić ustawienia SSH.

Szybki start (do uprządkowania)

Podstawowa obsługa Gita może być nieco zagmatwana dla początkujących. I tak:

• Tworzenie gałęzi to "git checkout -b".

"git branch" powinno być używane tylko do wylistowania i usuwania gałęzi.

• Współdzielisz swoją pracę przez "git fetch" (pobranie) i "git push" (wysłanie). To są przeciwieństwa.
• "git pull" może również zrobić "git fetch" ale to jest opcjonalne.
• Większość operacji wykonuje się przez "git polecenie".

Aby uzyskać pomoc na temat jakiegoś polecenia wpisujemy "git help polecenie" lub "git --help".

Obsługa git w edytorze vim

Uwaga! git nie dodaje pustych katalogów do repozytorium. To wynika z koncepcji, że git śledzi zawartość plików a nie pliki.

mkdir git_repo   # tworzymy katalog w którym będzie nasze repozytorium plików, możemy nazwać jak chcemy
cd git_repo      # przechodzimy do tego katalogu
git init         # inicjalizujemy bazę repozytorium (katalog .git)

Teraz wgrywamy do tego katalogu pliki lub tworzymy nowe.

git add .        # dodajemy wszystkie pliki do śledzenia z aktualnego katalogu, kropka oznacza właśnie katalog aktualny
git status       # sprawdzamy status naszego repozytorium, to polecenie pokaże które pliki zmienione, a które nowe
git commit -a    # zatwierdzamy zmiany czyli wysyłamy pliki do bazy repozytorium

Samo polecenie git commit zapisze tylko pliki, które zostały dodane poleceniem git add. Dlatego dodajemy -a, żeby nie dodawać ręcznie każdego zmienionego pliku. Nowe pliki trzeba jednak dodać przez git add.

git log          # sprawdzamy historię zatwierdzeń
git whatchanged -p # historia zmian razem z diff
git whatchanged --pretty=oneline # wyświetla tylko nazwy zmienionych plików

Jeśli chcemy, możemy rozgałęziać nasz projekt tworząc gałęzie. Domyślnie nowy projekt jest w gałęzi master. Wszystkie gałęzie można wylistować poleceniem

git branch

Znak * wskazuje aktualną gałąź.

Jeśli chcemy graficznie zobaczyć nasze drzewo kodu, to trzeba użyć polecenia gitk (w gentoo "gitview")

Przypadki użycia

Kopiowanie plików na serwer

Dodajemy zdalny serwer ( tutaj GitHub) :

git remote add github_c https://github.com/adammaj1/c

Sprawdzamy zdalne repo :

git remote show github_c

Otrzymujemy wynik :

* remote github_c
 Fetch URL: https://github.com/adammaj1/c
 Push  URL: https://github.com/adammaj1/c
 HEAD branch: master
 Remote branch:
   master new (next fetch will store in remotes/github_c)
 Local ref configured for 'git push':
   master pushes to master (local out of date)

Próbujemy wysłać pliki do zdalnego repozytorium ( ang. remote ):

git push github_c master

Najpierw musimy się zalogować :

Username: 
Password: 

Otrzymujemy odpowiedź :

To https://github.com/adammaj1/c
! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/adammaj1/c'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

Przyczyną błędu jest ... ( do zrobienia)

Rozwiązaniem jest :

git pull github_c master

Otrzymujemy :

From https://github.com/adammaj1/c
* branch            master     -> FETCH_HEAD
Merge made by recursive.
README.md |    4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 README.md

Następnie powtarzamy :

git push github_c master

I mamy pliki w zdalnym repo !

Usuwanie gałęzi ze zdalnego repo

git push origin :<branch_name>

Kopiowanie projektu z serwera

Na serwerze Gitorius zaintersował nas projekt Mandulia. Chcemy skopiować oprogramowanie na nasz komputer. W tym celu w konsoli wpisujemy :

git clone git://gitorious.org/maximus/mandulia.git

Otrzymujemy informacje gdzie projekt jest kopiowany :

Initialized empty Git repository in /home/user/mandulia/.git/

( powyższy katalog jest przykładowy).

Teraz możemy w konsoli przejść do tego katalogu

cd mandulia

lub użyć programu z GUI np. gitg

Wrzucanie do git aktualnego projektu

Załóżmy, że przechowujesz już swój projekt w katalogu projekt1, więc przechodzimy do tego katalogu

cd projekt1

Chcemy teraz, aby git śledził pliki z projektu i pozwalał nam zarządzać wersjami plików, przeglądać historię itp. Musimy więc utworzyć lokalne repozytorium, wewnątrz katalogu projekt1.

git init

Utworzony zostanie ukryty katalog projekt1/.git , w którym git będzie przechowywał wszystkie zmiany, które każemy mu pamiętać.

Następnie dodajemy wszystkie pliki do indeksu (coś jak poczekalnia dla plików)

git add .

Możemy sprawdzić co się zmieniło :

git status

Na koniec przenosimy pliki z poczekalni od repozytorium

git commit -m 'pierwszy zapis do repo'

Wszystkie te zmiany odbywają się lokalnie ( na naszym dysku , pomiędzy katalogiem roboczym projektu a lokalnym repozytorium = podkatalogiem katalogu roboczego)

Wrzucanie pojedynczego nowego pliku

Załóżmy, że stworzyliśmy nowy plik tekst.txt i chcemy go wrzucić do repozytorium. Tutaj też najpierw trzeba go wrzucić do poczekalni

git add tekst.txt

Dopiero potem wysyłamy plik do repozytorium.

git commit -m 'pierwszy plik'

Wrzucanie zmienionego pojedynczego pliku

Nasz plik tekst.txt już jest w repozytorium, ale zrobiliśmy zmiany, które chcemy zapisać w repozytorium. W tym przypadku możemy pominąć poczekalnię

git commit tekst.txt -m 'drobna zmiana'

Wrzucanie tylko zmienionych plików bez plików nie śledzonych

Załóżmy, że zmieniliśmy wiele plików, ale w naszym katalogu projekt1 są pliki, których nie chcemy w repozytorium jeszcze. Komenda git add . tu nam nie pomoże. Ale jest inna, która doda tylko pliki już śledzone przez git.

git add -A

Wrzucanie dwóch z wielu zmienionych plików

Znowu zmieniliśmy tekst.txt, ale także tekst2.txt oraz tekst3.txt. Chcemy jednak wysłać do zmiany dotyczące tekst.txt oraz tekst2.txt.

git commit tekst.txt tekst2.txt

Niejasności związane z git add

Uruchamiamy git add tekst.txt i cały plik tekst.txt jest wrzucany do indeksu. Razem z zawartością. Jeśli teraz wprowadzimy jakieś poprawki do tekst.txt i nie zrobimy znowu git add tekst.txt, to git commit tekst.txt wyśle do repozytorium starszą wersję znajdującą się w indeksie.

Dlatego git add używamy tylko w trzech wariantach:

git add .
git add nowy_plik
git add nowy_plik nowy_plik2 itd.

Dalsze operacje (do uprządkowania)

Wycofanie nie zapisanych zmian (dwa polecenia)

git checkout file-to-revert
git reset HEAD <file>

Cofnięcie wszystkich lokalnych zmian

git checkout -f

Cofanie zmian (do uprządkowania)

Poniższe polecenia działają na plikach już śledzonych. Jeśli chcemy usunąć także pliki nie śledzone, trzeba to zrobić ręcznie. Można najpierw usunąć wszystkie pliki poleceniem

rm -Rf *

To nie usunie katalogów o nazwach zaczynających się na kropkę czyli repozytorium .git.

git reset HEAD^         # nie ruszaj plików roboczych - pozostaw zmiany
git reset --hard HEAD^  # zresetuj również pliki robocze
git reset --hard HEAD~5 # cofnij się o 5 zapisów
git reset --hard origin # wyczyść wszystkie zmiany i zacznij od nowa

git-checkout -- nazwa_pliku # Przywróć ostatnią wersję pliku z repozytorium dla aktualnej gałęzi
git-checkout revision nazwa_pliku # Przywróć plik w wersji revision

Uwaga!

git-checkout revision #utworzy nam oderwaną gałąź, co nie koniecznie jest oczekiwane

git reset --hard revision # uaktualni HEAD i aktualną gałąź do
punktu określonego przez revision, i uaktualni drzewo robocze
aby odzwierciedlało nowy index.

Jeśli git reset --hard HEAD^ nie zadziała to trzeba trzeba inaczej

git reflog

wyświetli nam się lista operacji i znajdujemy numer tej operacji, do której chcemy wrócić.

git reset --hard HEAD@{1}

Inne

Unable to write new index file, czyli brak miejsca na dysku

OPis

Nie można ponowić czynności clone

Opis