[ Pobierz całość w formacie PDF ]
a nie obrazem (ang. snapshot). Numer wersji oznacza zestaw zmian (coÅ› w rodzaju Å‚atki), a nie
pełny eksport systemu. Druga ważna różnica dotyczy gałęzi. Ponieważ repozytorium jest przecho-
wywane lokalnie, gałęzie możesz tworzyć w nim lokalnie albo oznaczyć je do udostępniania innym.
Dlatego można tworzyć gałęzie na własny użytek, łączyć zmiany w udostępnianych gałęziach (albo
je wyrzucać), a następnie przekazywać je do innych repozytoriów.
Spo eczno ciowe narz dzia dla programistów
Nie można przy okazji omawiania narzędzia Git (i podobnych) nie wspomnieć o serwisach inter-
netowych, które powstały w związku z nim, np. GitHub13. Są to usługi hostingu systemów kon-
troli kodu zródłowego, dzięki którym można śledzić aktywność wybranego programisty albo ca-
łych zespołów. Zazwyczaj w serwisach tych udostępniane są strony wiki i podsystemy typu issue
tracker, czyli serwisy oferują właściwie wszystko, czego potrzeba do prowadzenia projektu pro-
gramistycznego. Jednak najważniejszą cechą systemów rozproszonych, dzięki której zyskały po-
pularność, jest możliwość sprawdzenia w dowolnej chwili, kto ma kopie repozytoriów i jakie zmiany
ten ktoś wprowadza. Ponadto za pośrednictwem serwisów społecznościowych użytkownicy mogą
wysyłać do nas żądania pobrania (ang. pull request) prośby o wciągnięcie dokonanych przez
nich zmian do naszej głównej gałęzi. Poza tym wiele z tych serwisów oferuje sieciowy interfejs do
wykonywania tego typu scaleń.
Istnieją serwisy internetowe dla wszystkich rodzajów systemów kontroli kodu zródłowego, włącznie
z Subversion. Są to doskonałe rozwiązania do pracy grupowej, a na dodatek większość z nich oferuje
darmowe konta dla projektów open source i płatne do użytku komercyjnego.
Kontrola kodu ród owego przy u yciu narz dzia Git
Wcześniej poznaliśmy zasadę działania systemu Subversion. W tej części rozdziału dokonamy
porównania tego narzędzia z rozproszonym systemem typu Git. Jedną z różnic między tymi
typami rozwiązań jest stosowane nazewnictwo. W systemach rozproszonych repozytoria się klonuje
(ang. clone), zamiast pobierać (ang. check out). Jeśli będziesz używać np. usługi GitHub, możesz na
początku rozwidlić (ang. fork) repozytorium, aby utworzyć własną wersję, która będzie ogólno-
dostępna i w której będziesz mógł zapisywać swój kod następnie klonujesz ją na swój komputer,
aby móc na niej pracować.
13
http://github.com/.
Poleć ksi k
Kup ksi k
256 Mistrz PHP. Pisz nowoczesny kod
Do klonowania repozytoriów służy polecenie clone. Poniżej znajduje się przykładowe polecenie
sklonowania z GitHub repozytorium otwartego projektu joind.in:
$ git clone git@github.com:lornajane/joind.in.git
Cloning into joind.in...
Program utworzy na Twoim komputerze nowy katalog o takiej samej nazwie jak repozytorium.
Gdy do niego przejdziesz, znajdziesz w nim kompletny kod. Aby pobierać zmiany z innych repo-
zytoriów, trzeba wiedzieć, czym są zródła zdalne (ang. remotes). Kontynuując poprzedni przy-
kład: chcielibyśmy pobierać zmiany z głównego projektu joind.in z GitHub, z którego utworzyliśmy
własne rozwidlenie repozytorium. W tym celu musimy go dodać jako zródło zdalne, a następnie
pobrać z niego zmiany:
$ git remote add upstream git@github.com:joindin/joind.in.git
$ git remote
origin
upstream
Dodaliśmy główne repozytorium projektu joind.in jako zródło zdalne o nazwie upstream (jest to
bardzo przydatny zwyczaj). Gdy wpiszemy polecenie git remote bez żadnych dodatkowych ar-
gumentów, otrzymamy listę wszystkich zdalnych zródeł znanych Git, włącznie z naszym zródłem
upstream i zródłem origin, czyli tym, z którego je sklonowaliśmy. Aby pobrać zmiany z repozyto-
rium upstream, należy użyć polecenia pull:
$ git pull origin master
Argumentami tego polecenia są nazwa zródła zdalnego i nazwa gałęzi, z której chcemy pobrać
zmiany. Własnych zmian można dokonywać poprzez standardowe edytowanie plików. Aby jed-
nak takie pliki zostały uwzględnione w zatwierdzeniu, w Git trzeba jeszcze je do niego dodać.
Za pomocą polecenia git status można sprawdzić, co zostało zmienione, które pliki nie są śle-
dzone oraz które zostały dodane do zatwierdzenia przy najbliższej okazji:
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: index.php
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add index.php
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: index.php
#
$ git commit -m "added comments to index.php"
Poleć ksi k
Kup ksi k
KONTROLA JAKO CI 257
[ Pobierz całość w formacie PDF ]