Podobne wpisy:

• 15.03.2010 -- Zdalne, współdzielone repozytorium GIT.
• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails
• 20.08.2009 -- Praca ze zdalnym repozytorium w GIT

Chciałbym jako uzupełnienie tamtego artykułu napisać krok po kroku jak skonfigurować zdalne repozytorium tak aby kilku programistów mogło się z nim łączyć przez ssh.

Czynności, które musimy wykonać po stronie serwera:

• Wybieramy miejsce na repozytorium, np. “/opt/repos/git” i przechodzimy do niego.

  $ cd /opt/repos/git

• Tworzymy grupę systemową ‘git’ i dodajemy do niej użytkowników, którzy mają dostęp do repozytorium
• Zmieniamy uprawnienia plików w ten sposób, aby członkowie tej grupy mieli prawo zapisu we wszystkich podfolderach tego katalogu. Zablokować zapis dla innych.

  $ chmod o-w .
  $ chgrp -R git .
  $ chmod -R g+swX .

• Teraz jeżeli chcemy stworzyć nowe repozytorium, to tworzymy nowy katalog:

  $ mkdir sample.git

• Następnie inicjujemy współdzielone repozytorium:

  $ git init --bare --shared

To wszystko, jak współdziałać z takim repozytorium zostało opisane w tym artykule

Jeżeli chcemy aby użytkownik, który został dodany do systemu, miał możliwość tylko korzystania z repozytorium – chcielibyśmy wyłączyć mu standardowe logowanie to musimy zmienić mu w ustawieniach powłokę z ‘/bin/login’,na ‘/usr/bin/git-shell’ . Taka powłoka pozwoli łączyć się tylko i wyłącznie z repozytorium gita. Próbla zalogowania się do systemu spowoduje wyświetlenie komunikatu:

" fatal: What do you think I am? A shell?"

Udanego gitowania.

Podobne wpisy:

• 30.07.2010 -- Logi gita i kolorowe głowice
• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails
• 20.08.2009 -- Praca ze zdalnym repozytorium w GIT


$ rails my_app
$ cd my_app
$ git init
$ git status
...
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# README
# Rakefile
# app/
# config/
# db/
# doc/
# log/
# public/
# script/
# test/


Wydanie komendy git status pokazało nam całą strukturę aplikacji, która nie jest objęta kontrolą wersji. Zanim dodamy, powinniśmy wyłączyć kilka plików. Po pierwsze w repozytorium nie potrzebujemy plików dzienników („logów”), które znajdują się w folderze log. Aby je wyłączyć musimy stworzyć plik .gitignore i dodać linijkę log/*.log.

$ echo „log/*.log” >>.gitignore

Ponowne sprawdznie statusu pozwoli nam zauważyć zmianę, która zaszła w repozytorium.


$ git status
…
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# .gitignore
# README
# Rakefile
# app/
# config/
# db/
# doc/
# public/
# script/
# test/
nothing added to commit but untracked files present (use "git add" to track)

Folder log zniknął z listy plików do dodania. Problem polega na tym, że klonująć potem repozytorium, otrzymamy jest bez tego folderu. Gdy uruchomimy aplikację, będą problemy z jej działaniem, ponieważ w tym folderze logi muszą być zapisywane.
Naszym zadaniem zatem jest ustawienie repozytorium tak, aby sam folder znajdował się w nim, a ignorowana powinna być jedynie jego zawartość. Cała powyższa sytuacja dzieję się tak dlatego, że system Git nie śledzi pustych folderów. Wyjściem z tej sytuacji jest trick, polegającym na dodaniu pliku .gitignore w folderze log. Folder nie będzie pusty, a jednocześnie dodany plik, nie będzie miał wpływu na nasz projekt.


$ touch log/.gitignore
$ git status
…
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# .gitignore
# README
# Rakefile
# app/
# config/
# db/
# doc/
# log/
# public/
# script/
# test/
nothing added to commit but untracked files present (use "git add" to track)

Na powyższym listingu widać, że osiągnęliśmy zamierzony efekt. Podobny problem występuje w folderze tmp, którego zawartość również powinna być ignorowana, nie ignorując samgo folderu. Nauczeni powyższym doświadczeniem dodajemy plik .gitignore w tym katalogu, a w .gitignore znajdującym się w głównym folderze aplikacji dopisujemy tmp/**/*. Co oznacza ignorowanie wszystkich plików nawet w podfolderach.
Warto również zignorować dwa foldery z dokumentacją, które niepotrzebnie zajmują miejsce w repozytorium. Po dopisaniu dwóch linijek w głównym pliku .gitignore, powinien on zawierać taką treść:

log/*.log
tmp/**/*
doc/api
doc/app
Teraz możemy dodać wszystkie pliki i wykonać początkowe zatwierdzenie.

$ git add .
$ git commit -a -m „rozpoczęcie pracy”


W praktyce warto przenieść zewnętrzną bibliotekę rails, wewnątrz aplikacji, co pomoże w późniejszym uruchamianiu projektu na serwerze produkcyjnym. Aby to zrobić musimy wykonać komendę rake rails:freeze:gems co spowoduje przeniesienie całego frameworka, do folderu vendor/rails. Aplikacja przeszukuje ten folder w pierwszej kolejności i dopiero gdy go nie znajdzie, to szuka po zainstalowanych w systemie gemach.
Po wykonaniu powyższej komendy wystarczy zatwierdzić kolejną zmianę.

$ git add vendor
$ git commit -a -m „Dodanie frameworku do fodleru vendors”
Teraz nie pozostaje nic innego niż rozpoczęcie pracy nad projektem.

W sumie nie stoi nic na przeszkodzie, aby powyższy zaimplikować w Rails Template, ale o tym jak to się robi, napiszę już niedługo.

Podobne wpisy:

• 16.07.2010 -- Pickle na Rails3
• 05.03.2010 -- Rails Template
• 12.12.2009 -- Automatyczny start czyli Rails Templates

Większość projektów nie jest prowadzona samodzielnie, jest w niego zaangażowane kilku (-nastu, -dziesięciu) innych programistów. Każdy z nich może lokalnie prowadzić własną ścieżkę, ale z doświadczenia wiem, że przydaje się jedno wspólne repozytorium. Punkt centralny dla naszej pracy.

Inicjalizacja repozytorium

Przypuśćmy, że posiadamy serwer w domenie projekty.pl i tam chcemy założyć nasze centralne repozytorium. W tym celu logujemy się na naszym serwerze:

 > ssh projekty.pl 
cd /repos
mkdir gittutor.git
cd gittutor.git
git --bare init
exit

To wszystko. Wszystkie powyższe komendy za pewne są jasne, tylko jedna może nasuwać pewne niepewności:

 git --bare init

Co daje nam atrybut –bare? Otóż w naszym zdalnym repozytorium nie potrzebujemy kopii plików projektu tylko samą informację o repozytorium. To właśnie robi atrybut –bare – tworzy strukturę plików repozytorium, do którego możemy się połączyć tylko zdalnie bez plików projketu wewnątrz.

Po wylogowaniu się z naszego serwera wracam do naszego projektu na lokalnym komputerze.

 > cd /projekty/gittutor

który jest już pod kontrolą wersji. Wydajemy komendę:

 > git remote add centrala ssh://projekty.pl/repos/gittutor.git

git remote add

dodaje nowe zdalne repozytorium,

 centrala

nasza nazwa tego zdalnego repozytorium,

 ssh://projekty.pl/repos/gittutor.git

url do tego zdalnego repozytorium.

Sprawdźmy, czy dodano nasze zdalne repozytorium:

 > git remote show centrala
* remote centrala
  URL: ssh://projekty.pl/repos/gittutor.git
  HEAD branch: (unknown)

Wysyłanie plików na zdalny serwer

Do synchronizacji lokalnego repozytorium ze zdalnym wykonujemy za pomocą komend git push oraz git pull. Spóbujmy wysłać pliki do naszego zdalnego repozytorium:

 > git push centrala master

Jako pierwszy argument podajemy nazwę zdalnego repozytorium, jako drugi lokalny branch, który ma być wysłany.

Counting objects: 32, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (32/32), 2.72 KiB, done.
Total 32 (delta 4), reused 0 (delta 0)
To ssh://projekty.pl/repos/gittutor.git
 * [new branch]      master -> master

W ten sposób umieściliśmy nasz projekt w zdalnym repozytorium.

Klonowanie repozytorium

Teraz gdy nasze pliki znajdują się w zdalnym repozytorium możemy je w prosty sposób sklonować (np. dla nowego członka zespołu pracującego nad projektem).

 > git clone ssh://projekty.pl/repos/gittutor.git
 
Initialized empty Git repository in /projekty/gittutor2/gittutor/.git/
remote: Counting objects: 32, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 32 (delta 4), reused 0 (delta 0)
Receiving objects: 100% (32/32), done.
Resolving deltas: 100% (4/4), done.
 
cd gittutor
git remote show
 
origin

“origin” jest domyślną nazwa nadawaną dla zdalnego repozytorium. Zauważmy, że po klonowaniu w naszym projekcie jest ustawione zdalne repozytorium (to z którego klonowaliśmy pliki) – nie musimy tego robić ręcznie.

Praca ze zdalnym repozytorium

Sprawdźmy jeszcze jeden ciekawy scenariusz – jeden z programistów zakłada własny projekt od zera i synchronizuje go z naszym zdalnym repozytorium.

> mkdir gittutor3
cd gittutor3
git init
git remote add origin ssh://projekty.pl/repos/gittutor.git
 
echo "plik2" > nowy_plik.txt
git add nowy_plik.txt
git commit -m "Dodano nowy plik"
[master (root-commit) 577763f] Dodano nowy plik
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 nowy_plik.txt

Co zrobiłem? Utworzyłem nowy katalog, dodałem go do kontroli wersji (’init’) ustawiłem zdalne (dobrze nam znane ) repozytorium. Następnie dodałem plik i skommitowałem go do lokalnego repozytorium.
Teraz musimy wysłać naszego brancha na serwer. Po nazwie lokalnego musimy podać nazwę pod jaką nasz branch będzie widniał w zdalnym repozytorium (po dwukropku)

> git push origin master:fajny_projekt
 
Counting objects: 3, done.
Writing objects: 100% (3/3), 223 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://projekty.pl/repos/gittutor.git
 * [new branch]      master -> fajny_projekt

Teraz przełączmy się do folderu z którego rozpoczęliśmy pracę

 cd ../gittutor 
> git remote show centrala
 
* remote centrala
  URL: ssh://projekty.pl/repos/gittutor.git
  HEAD branch: master
  Remote branches:
    fajny_projekt new (next fetch will store in remotes/centrala)
    master        tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

Widać, że zdalny branch jest widoczny – jednak w jaki sposób się na niego ‘przełączyć’? Najpierw musimy zaktualizować nasz mirror zdalnego repozytorium:

 > git fetch centrala
Unpacking objects: 100% (3/3), done.
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From ssh://projekty.pl/repos/gittutor
 * [new branch]      fajny_projekt -> centrala/fajny_projekt
 
git remote show centrala
 
* remote centrala
  URL: ssh://projekty.pl/repos/gittutor.git
  HEAD branch: master
  Remote branches:
    fajny_projekt tracked
    master        tracked
  Local ref configured for 'git push':
    master pushes to master (up to date)

aktualnie skopiowaliśmy zdalny fajny projekt do lokalnego repozytorium.
Można go zobaczyć na liście branchy

 > git branch -a
* master
  remotes/centrala/fajny_projekt
  remotes/centrala/master

Jeżeli teraz chcemy dokonać zmian na tym zdalnym repozytorium musimy utworzyć lokalnego brancha, który będzie śledził (tracking) ten zdalny.

 > git checkout --track -b fajny_projekt centrala/fajny_projekt
Branch fajny_projekt set up to track remote branch fajny_projekt from centrala.
Switched to a new branch 'fajny_projekt'

Utworzono lokalny branch pod nazwą ‘fajny_projekt’ ze zdalnego ‘centrala/fajny_projekt’ i od razu zaznaczono go jako aktywny sprawdźmy:

 > git branch -a 
* fajny_projekt
  master
  remotes/centrala/fajny_projekt
  remotes/centrala/master
 
> ls
nowy_plik.txt

Mam nadzieję, że wszystko jest zrozumiałe, jest późno – a o tej godzinie to czasami sam nie do końca wiem co piszę . W razie nieścisłości proszę o słówko w komentarzach.

Podobne wpisy:

• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails
• 19.08.2009 -- Spring jest GIT
• 17.08.2009 -- GIT Stash

Podobne wpisy:

• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails
• 20.08.2009 -- Praca ze zdalnym repozytorium w GIT
• 17.08.2009 -- GIT Stash

Wielce mnie ucieszyło, gdy zobaczyłem podczas pracy z GIT, że ma on taką funkcję wbudowaną out-of-the-box. Nazywa się ona ‘Stash’.
Wykonuje ona operację dokładnie tak jak opisałem powyżej, czyli…
1. Pracując z dłuższym kawałkiem kodu, mamy już sporo zmian, gdy dostrzegamy błąd aplikacji, który natychmiastowo powinniśmy poprawić.
2. Wykonujemy komendę

 > git stash save "nazwa stasha"

Wykonanie tej operacji zachowa nasze dotychczasowe zmiany gdzieś na boku, a master tree przywróci do stanu HEAD.
3. Możemy poprawić nasz błąd i wykonać commit

 > git commit -a -m "bugfix #2382

4. Przywracamy stan poprzedni, aby kontynuować pracę:

 > git pop

co jednocześnie usunie naszą “szufladkę”, jeżeli nie chcemy usuwać aby móc do tego stanu jeszcze wrócić wykonujemy komendę :

 > git apply

5. Kontynuujemy pracę.

Git Stash ma więcej możliwości, bo takich wirtualnych szufladek możemy tworzyć dowolną ilość i przywracać stan z każdej z nich. Możemy zatem poprogramować w stylu “co by było gdyby…” i wybrać najbardziej odpowiednią wersję napisanego kodu (dotyczy to zwłaszcza młodych programistów, którzy niejednokrotnie nie są pewni podejmowanych decyzji w programowaniu).

Młody czy stary programista – polecam GIT i funkcję stash.

Więcej o tej komendzie znajdziecie tutaj.

Podobne wpisy:

• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails
• 20.08.2009 -- Praca ze zdalnym repozytorium w GIT
• 19.08.2009 -- Spring jest GIT

1. Wprowadzenie

GIT jest systemem kontroli wersji, którego używał Linus Torvalds podczas pracy nad kernelem linuxa – z resztą do tej pory kernel jest kontrolowany przez GIT. Główną różnicą od svn, która skłoniła mnie do korzystania z niego, jest jego decentralizacja. W Subversion niezbędne jest stworzenie jednego głównego repozytorium które kontroluje nasz projekt. Każdy klient łączy się z tym centralnym repozytorium podczas pracy nad projektem i każda zmiana musi być wysłana na serwer. GIT działa w architekturze P2P repozytorium nie musi być centralne. Może istnieć kilka równoległych, które będą potem synchronizowane. Istnieje nawet możliwość synchronizacji przez mail Oczywiście nic nie stoi na przeszkodzie, aby używać centralnego repozytorium, zwłaszcza podczas pracy nad dużym projektem. Niejednokrotnie jednak miałem odwrotną sytuację – pracowałem nad czymś małym, a mój edytor (vim ) nie posiada wbudowanej obsługi kontroli wersji. Chcąc objąć projekt kontrolą nie chciało mi się tworzyć repozytorium svn – bo za dużo roboty. Więc praca którą wykonywałem była ‘na żywioł’. Cofnięcie wersji było równoznaczne z napisaniem kodu od nowa.

Od tego czasu ropocząłem korzystanie z git. Sami zobaczcie jakie to proste. Opiszę kilka podstawowych operacji potrzebnych do pracy z lokalnym repozytorium. Jeżeli mi się uda, to w późniejszym czasie opiszę sposoby pracy z repozytorium zdalnym.

2. Tworzymy projekt

Na początek coś o niezbyt skomplikowanej strukturze :



W języku “GITowym” projekt, nad którym pracujemy jest nazwany working tree.

Wszystko co musimy zrobić, aby objąć projekt kontrolą wersji jest użycie komendy:

 > git init

Spowoduje to utworzenie ukrytego folderu .git, w którym umieszczane są informacje o naszym projekcie.

W większości systemów kontroli wersji, przechowywanie informacji o plikach umiejscowia się w dwóch miejscach. Bezpośrednio w projekcie lub w centralnym repozytorium. GIT wprowadził coś nowego – warstwę pośrednią pomiędzy projektem, a repozytorium: Staging area (lub Staging Index). W indeksie tym przechowywane są informacje o całym naszym projekcie, tu kontroluje się zmiany i w przypadku, gdy jesteśmy ze zmian zadowoleni to je commitujemy do repozytorium. Daje to nam taką korzyść, że nie zaśmiecamy ani projektu, ani repozytorium zbędnymi informacjami.

3. Staging index

Aby wprowadzić plik do indexu wystarczy wydać komendę:

> git add

Warto zauważyć, że index przechowuje informacje o wszystkich plikach, nie tylko o plikach zmienionych.

Dodajemy nasz plik do projektu:

> git add plik1.txt

Oraz cały folder:

> git add folder1

Teraz wszystkie pliki, które posiadamy znajdują się w Staging area.



W każdej chwili, możemy zobaczyć, co się zmieniło w naszym projekcie od ostatniego zatwierdzenia (commit) wydając komendę:

> git status

Pokazywany nam jest raport ze zmianami w naszym working tree. Pliki mogą być wymienione w dwóch oddzielnych sekcjach raportu: pliki zmienione i dodane do staging area oraz pliki zmienione i nie dodane do staging area.

4. Zatwierdzanie zmian

Gdy wszystkie zmiany, których dokonaliśmy są OK musimy je zatwierdzić. Dokonujemy tego poleceniem:

> git commit

otworzy się edytor, gdzie należy wpisać opis commitu. Jeżeli tytuł jest krótki, możemy go wpisać od razu przy commicie za parametrem ‘-m’. Na przykład:

> git commit -m "initial commit"



W GIT nie nadaje się liczbowych numerów rewizji, tak jak ma to miejsce np. w Subversion. Tutaj każdy commit jest określony kluczem SHA wyliczanym na podstawie zawartości working tree. Dla przykładu w moim prostym projekcie pierwszy commit otrzymał identyfikator:

 52e0188f4b5f082427cc9df07451cc5daa169f63

Może na początku wydawać nam się dziwne takie identyfikowanie wersji, ale jest skuteczne. Zwłaszcza, że musimy pamiętać o architekturze systemu git. Tutaj nie ma centralnego repozytorium i można prowadzić dwa równoległe. Gdy po jakimś czasie zdecydowalibyśmy się na synchronizację to byłby problem, bo w każdym repozytorium znalazłyby się rewizje 1, 2, 3 itd. ale zawartości tych rewizji byłyby różne. Aby zapobiec takim sytuacjom wprowadzono klucz SHA jako identyfikator. Co jednak jeżeli w przyszłości chcielibyśmy cofnąć nasz projekt do któregoś momentu? Czy musimy podać cały klucz? Otóż nie. Wystarczy podać tyle pierwszych znaków ile wystarczy na jednoznaczne zidentyfikowanie. W przypadku na przykład gdy mamy dwie rewizje i klucz każdej zaczyna się od innej literki (albo cyferki) to wystarczy podać pierwszy znak klucza aby jednoznacznie zidentyfikować. Niepisaną regułą jest podawanie 7-iu znaków do identyfikacji rewizji. Jest to wystarczająca w większości przypadków liczba jednoznacznie identyfikująca. Tyle też znaków jest podawanych po zcommitowaniu zmian w raporcie.



Commit tak samo jak Staging area jest “stemplem” całego working tree – są tam informacje o wszystkich plikach i folderach znajdujących się w danym momencie, a nie tylko te, które się zmieniły.



Podsumowując: cała operacja kontroli wersji wykonywana jest w trzech krokach: Pierwszym krokiem jest zmiana zawartości working tree, np. dodanie pliku, usunięcie pliku lub edycja pliku. Drugim krokiem jest zatwierdzenie tej zmiany i przeniesienie jej do Staging area poprzez wykonanie komendy git add. Trzecim krokiem jest zatwierdzenie zmian poprzez git commit i przeniesienie całego Staging index do Commit.

Co to nam daje? Wyobraźmy sobie, że pracujemy z większym projektem. Dokonaliśmy już kilkadziesiąt modyfikacji i nagle otrzymujemy wiadomość, że w jednym z plików jest poważny błąd. Naprawiamy go, stage’ujemy go (git add) a następnie commitujemy poprawkę. Po czym spokojnie wracamy do naszej pracy, bo reszta plików, którą zmieniliśmy podczas naszej dotychczasowej pracy została nietknięta w naszym working tree. Jak dokonalibyśmy tego w subversion? Musielibyśmy się nakombinować z filelock albo z branchami. Tu mamy to out-of-the-box.

Może wydawać się trudne prowadzenie w ten sposób repozytorium, ale po krótkim czasie przyzwyczajamy się, a po kilku chwilach potem nie będziemy potrafili bez tego żyć

Istnieje także ułatwienie aby oba kroki dokonać za jednym razem. Podczas commita dodajemy parametr -a i wszystkie pliki, które zostały zmienione (ale nie te co zostały dodane) automatycznie przenoszone są do Staging index i wykonywany jest commit.

5. Sprawdzanie zmian

Aby zobaczyć co działo się w naszym repozytorium wystarczy wykonać komendę :

> git log

Wyświetli nam się lista zmian, rozpoczynając od ostatniej. Podane są informacje o symbolu commita, autorze, dacie i wiadomość, która została wpisana wraz z commitem.
Dodanie parametru --pretty=oneline pokaże w jednej lini klucz sha i message, a dodanie jeszcze parametru --abbrev=commitskróci klucz do 7-miu znaków.

6. Przykład

Myślę, że w tym miejscu należy się jakiś solidny przykład do komend, które właśnie poznaliśmy. Zatem wracając do przykładu z początku artykułu – pracujemy nad bardzo ubogim projektem posiadającym jeden plik w folderze głównym oraz jeden folder z drugim plikiem.
Wykonujemy

> git init

aby zainicjować kontrolę wersji. Zaraz potem wykonujemy

> git status

aby zobaczyć co się zmieniło. Otrzymujemy:

...
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       folder1/
#       plik1.txt

Czyli zarówno plik jak i folder nie są pod kontrolą wersji. Dodajmy plik:

> git add plik1.txt

i sprawdźmy status raz jeszcze:

...
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#       new file:   plik1.txt
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       folder1/

W tej chwili gdybyśmy wykonali commit – dodałoby do commita tylko plik a nie folder. Nie chcemy tego (na razie) więc dodajmy także folder.

> git add folder1
 
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#       new file:   folder1/plik2.txt
#       new file:   plik1.txt

i zatwierdzamy zmiany jako “inital commit” czy jak tam chcemy nazwać:

> git commit -m "initial commit"

Od razu otrzymujemy odpowiedź:

[master (root-commit) 68c7006] initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)

widać nazwę commita oraz 7znaków klucza SHA. Sprawdźmy status:

> git status
...
nothing to commit (working directory clean)

Czyli jest ok. Sprawdźmy zatem staging w praniu. Zmieńmy zawartość obu plików i sprawdźmy status:

...
#       modified:   folder1/plik2.txt
#       modified:   plik1.txt

teraz jeden plik dodajmy do staging area i zcommitujmy:

> git add plik1.txt
> git status
...
#       modified:   plik1.txt
#
# Changed but not updated:
#
#       modified:   folder1/plik2.txt
...
> git commit -m "2nd commit"
[master 4741a87] 2nd commit
 1 files changed, 1 insertions(+), 1 deletions(-)
> git status
...
# Changed but not updated:
#
#       modified:   folder1/plik2.txt

Czyli jest tak jak zamierzaliśmy – w commicie znalazł się tylko plik1.txt – plik2.txt pozostał dalej w working tree. Zmieńmy ponownie plik1.txt i dodajmy do staging area – wrócimy do poprzedniej sytuacji..

> vim plik1.txt
> git add plik1.txt
> git status
# Changes to be committed:
#       modified:   plik1.txt
#
# Changed but not updated:
#       modified:   folder1/plik2.txt

czyli posiadamy dwa edytowane pliki, ale jeden tylko w staging index. Spróbujmy zatwierdzić je oba razem:

> git commit -a -m "3rd commit"
[master 1ed35d3] 3rd commit
 2 files changed, 2 insertions(+), 1 deletions(-)
> git status
# nothing to commit (working directory clean)

Nice… dodało oba pliki, ten który był w staging area oraz drugi który nie był. Pamiętajmy, że w przypadku, gdy dodamy nowy plik to musimy go ręcznie dodać do staging index.
Rzućmy okiem na log naszego repozytorium:

> git log --pretty-oneline --abbrev-commit
1ed35d3 3rd commit
4741a87 2nd commit
68c7006 initial commit

Możemy także z ciekawości zerknąć na to co wyświetli nam samo git log

Skoro przyjęliśmy już jakiś zakres wiedzy jedźmy dalej:)

7. Cofanie zmian

Co jednak jeżeli chcemy cofnąć zmiany, które wykonaliśmy na plikach? Wszystko zależy od tego jak daleko chcemy się cofnąć. Inaczej jest gdy zmiany nie zostały dodane do staging area a inaczej, jeżeli pliki już są dodane.

Jeżeli pliki nie są w staging area wystarczy wykonać komendę

> git checkout nazwa_pliku_lub_folderu

Sprawdźmy:

> git status
nothing to commit (working directory clean)
> echo "jakiś tekst" >> plik1.txt
> git status
# Changed but not updated:
#
#       modified:   plik1.txt
> git checkout plik1.txt
> git status
nothing to commit (working directory clean)

Jeżeli nie podamy nazwy pliku to zostaną cofnięte wszystkie zmiany w naszym working tree


Jeżeli pliki są dodane już do staging area, musimy je najpierw z niego “wyjąć” a potem dopiero cofnąć zmiany. Do tego służy komenda

> git reset HEAD nazwa_pliku

Jeżeli nie podamy nazwy pliku to zostaną zresetowane wszystkie. Dopiero jak plik zresetujemy to możemy go cofnąć poprzez git checkout
HEAD odnosi się zawsze do ostatniego commita


Przykład:

> git status
nothing to commit (working directory clean)
> echo "napis" >> plik1.txt
> git add plik1.txt
> git status
...
# Changes to be committed:
#
#       modified:   plik1.txt
> git reset HEAD plik1.txt
> git status 
# Changed but not updated:
#
#       modified:   plik1.txt
> git checkout plik1.txt
> git status
nothing to commit (working directory clean)

8. Cofanie zmian zatwierdzonych

Zawsze podczas pracy jest tak, że trzeba się cofnąć do poprzedniego commita. Jeżeli będziemy do tego zmuszeni to dokonamy tego poprzez

> git revert klucz_SHA_commita_do_ktorego_sie cofamy

(Oczywiście, że klucz wystarczy podać w postaci 7-io zakowej. ) Co się wtedy stanie? Technicznie nie cofamy się lecz idziemy do przodu – zostaje utworzony nowy commit, który jest identyczny wraz z commitem do którego się odnosimy:

> git log --pretty=oneline --abbrev-commit
1ed35d3 3rd commit
4741a87 2nd commit
68c7006 initial commit
> git revert 1ed35d3
> git log --pretty=oneline --abbrev-commit
3503b43 Revert "3rd commit"
1ed35d3 3rd commit
4741a87 2nd commit
68c7006 initial commit

Nic nie stoi na przeszkodzie, abyśmy cofnęli się dalej niż do ostatniego commita, jednak to może powodować problemy z synchronizacją (a o tym jak je rozwiązywać będzie później). Cofamy się do commita “2nd commit”:

> git revert 4741a87
> git log --pretty=oneline --abbrev-commit
d4976a7 Revert "2nd commit"
3503b43 Revert "3rd commit"
1ed35d3 3rd commit
4741a87 2nd commit
68c7006 initial commit



9. Porównywanie wersji

Jeżeli chcemy obejrzeć różnice między naszym working tree a commitem używamy komendy :

> git show 76a7c8c

używając oczywiście klucza commita, do którego chcemy się porównywać.
Jeżeli jednak chcemy obejrzeć różnice pomiędzy dwoma różnymi commitami to używamy komendy:

 > diff adf8342..78adc87

Gdy chcemy obejrzeć całą historię zmian, która nastąpiła w naszym projekcie to używamy:

> git log -p

10. Tagowanie

Głównym problemem Subversion jest to, że tagowanie repozytorium polega na kopiowaniu całego repozytorium w inne miejsce. Przy dużych projektach może to być problem ze względu na szybko rozrastające się repozytorium. W GIT’cie tego nie ma. Gdy chcemy robić taga, to po prostu oznaczamy jednego z commitów i nie tracimy miejsca na dysku. Tagowanie jest przydatne o tyle, że możemy używać taga zamiast klucza SHA odwołując się do tego konkretnego commita. W jaki sposób tagujemy? Jeżeli chcemy otagować ostatniego commita wystarczy podać:

> git tag nazwa_taga

Jeżeli jednak chcemy otagować commita, który nie jest ostatnim, to musimy podać jego klucz SHA na końcu:

> git tag nazwa_taga 7ad87cc

Naturalną czynnością jest tagowanie kolejnych wersji naszego projektu, np.

> git tag 0.97

Jak już wspomniałem, można używać tagów zamiast kluczy SHA, np.:

> git diff wersja_1..wersja_1.2

porównuje commity otagowane kolejno “wesja_1″ oraz “wersja_1.2″


11. Praca równoległa

Pracując w większych zespołach nad jednym projektem zdarza się, że każdy z członków zespołu pracuje nad inną funkcjonalnością. Są jakoby prowadzone dwie (lub więcej) równoległych ścieżek powstawania projektu. Oba te ‘podprojekty’ będą połączone w całość. Może być nawet tak, że chcemy “wypróbować” czy np. nowa technologia będzie dobrze działać z naszym projektem. Nie warto wtedy robić tego w głównej ścieżce powstawania tylko wypada zrobić równoległą. Takie równoległe nazywa się gałęziami (branches). Branchowanie to rozdzielanie projektu na kilka równoległych ścieżek powstawania, gdzie na koniec oba branche mogą zostać połączone z powrotem w jedną ścieżkę (merging). Automatycznie gdy inicjujemy projekt powstaje branch o nazwie master. Jest to główna ścieżka powstawania projektu. Mogliśmy zauważyć tą nazwę np. podczas dokonywania commitu. Jeżeli chcemy zobaczyć który branch jest aktualny wydajemy komendę:

> git branch -v

Ukaże nam się informacja o nazwie brancha, kluczu commita i jego nazwie, np.:

* master d4976a7 Revert "2nd commit"

Listę branchy możemy w każdej chwili zobaczyć wydając komendę:

> git branch

gwiazdka przy nazwie oznacza aktualny branch

Tworzenie oddzielnej gałęzi

Stworzenie nowego brancha sprowadza sie do wydania komendy git branch wraz z jego planowaną nazwą oraz kluczem commita, który ma być jakby punktem startowym dla tej gałęzi. Jak zawsze, jeżeli nie podamy klucza to będzie użyty aktualny commit.

> git branch slave 
> git branch
* master
  slave

Przełączanie się między branchami
Aby przełączyć się pomiędzy gałęziami musimy użyć komendy git checkout z nazwą brancha którego chcemy użyć.

> git branch
* master
  slave
> git checkout slave
Switched to branch 'slave'
> git branch
 master
* slave




Teraz wszystkie zmiany których dokonamy będą zatwierdzane w tej gałęzi

> echo "jestem w branchu" >> plik1.txt
> git commit -a -m "4th commit"
> git branch -v
 master d4976a7 Revert "2nd commit"
* slave  36e4883 4th commit


Przełączając się między gałęziami aktywujemy ostatni commit tej gałęzi, np. wykonianie

> git checkout master

aktywuje commit, w którym gałęzie się rozdzieliły (akurat w tym przypadku) i każdy koleny commit będzie od tego miejsca w tej właśnie ścieżce.


> echo "jestem w głównej ścieżce" >> folder1/plik2.txt
> git commit -a -m "5th commit"
> git branch -v
* master b1e1e1b 5th commit
  slave  36e4883 4th commit


W systemie GIT tworzenie branchy jest tak samo “tanie” jak tagów. To jest jeden z powodów “wyższości GIT nad Subversion” (moim zdaniem). W związku z tanim kosztem utworzenia brancha, niektórzy programiści tworzą je przy każdej okazji (nowy feature w nowym branchu).
W życiu każdego projektu podzielonego na kilka gałęzi nadchodzi taka chwila, gdzie trzeba będzie się z powrotem połączyć.

12. Łączenie równoległych gałęzi

Jak już prędzej gdzieś napisałem – łączenie dwóch równoległych gałęzi nazywa się mergingiem(nie podoba mi się spolszczanie angielskich wyrazów, jeśli jednak chodzi o język techniczny to nie mam nic przeciw – bo każdy może sobie przetłumaczyć inaczej i nie zrozumiemy nawet prostych przekazów.)

Łączenia dokonujemy z gałęzi do której łączymy ( przeważnie jest to master, czyli główna linia projektu) i podajemy nazwę brancha który ma być włączony. Dla przykładu aktualnie jesteśmy w masterze w Commit’cie “5th commit” i chcemy połączyć się z branchem “slave”:

> git merge slave
Merge made by recursive.
 plik1.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

tym razem obyło się bez problemów.
W gałęzi master został utworzony nowy commit (nazwany “merge branch ’slave’”) w którym zostały uwzględnione poprawki z obu gałęzi.
Czasami jednak nie jest tak wesoło. Zwłaszcza gdy w obu ścieżkach wyedytujemy ten sam plik. Spróbujmy wyedytować plik1.txt w obu gałęziach jednocześnie.

> echo "master górą" >> plik1.txt 
> git commit -a -m "6th commit"
[master 539525c] 6th commit
> git checkout slave
Switched to branch 'slave'
> echo "master dołem" >> plik1.txt
> git commit -a -m "7th commit"
[slave 9705a98] 7th commit

Teraz przełączamy się z powrotem do głównej gałęzi i robimy merge

> git checkout master
Switched to branch 'master'
 > git merge slave
Auto-merging plik1.txt
CONFLICT (content): Merge conflict in plik1.txt
Automatic merge failed; fix conflicts and then commit the result.

Niestety w równoległej pracy często tak się zdarza, że sa konflikty. Jak je ominąć? Musimy wyedytować konfliktowy plik. Zobaczymy tam coś takiego:

<<<<<<< HEAD:plik1.txt
master górą
=======
master dołem
>>>>>>> slave:plik1.txt

Dopisane zostały wersje z obu plików wraz z nagłówkami, która wersja pochodzi z której gałęzi. W takim wypadku musimy ręcznie usunąć tą wersją, która jest zła, oraz oba nagłówki. Następnie musimy dodać plik do staging area poprzez git add plik1.txt i to wszystko – po konflikcie.

Na koniec wypada usunąć nieużywaną gałąź używając komendy:

> git branch -d slave

i po kłopocie

Mam nadzieję, że chociaż troszeczkę przybliżyłem pracę z systemem kontroli wersji GIT. W najbliższym czasie postaram się opisać bardziej zaawansowane możliwości tego systemu.
Miłego mergowania.

Podobne wpisy:

• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails
• 20.08.2009 -- Praca ze zdalnym repozytorium w GIT
• 19.08.2009 -- Spring jest GIT