tmp/basic.txt

   1 == Pierwsze kroki ==
   2
   3 Zanim utoniemy w morzu poleceń Gita, przyjrzyjmy się najpierw kilku prostym poleceniom. Pomimo ich prostoty, wszystkie jednak są ważne i pożyteczne. W rzeczywistości, podczas pierwszych miesięcy pracy z Git nie wychodziłem poza zakres opisany w tym roźdźiale
   4
   5 === Zabezpieczenie obecnego stanu ===
   6
   7 Zamierzasz przeprowadzić jakieś drastychne zmiany? Zanim to zrobisz, zabezpiecz najpierw dane w aktualnym katalogu.
   8
   9  $ git init
  10  $ git add .
  11  $ git commit -m "Mój pierwszy commit"
  12
  13 Teraz, jeśli cokolwiek stałoby się z twymi plikami podczas edycji, możesz przywrócić pierwotną wersję:
  14
  15  $ git reset --hard
  16
  17 Aby zapisać nowy stan ponownie:
  18
  19  $ git commit -a -m "Mój następny commit"
  20
  21 === Dodanie, kasowanie i zmiana nazwy ===
  22
  23 Powyższa komenda zatrzyma jedynie pliki, które już istniały podczas gdy poraz pierwszy wykonałes polecenie *git add*. Jeśli w międzyczasie dodałeś jakieś nowe pliki, Git musi zostać o tym poinformowany:
  24
  25  $ git add readme.txt Dokumentacja
  26
  27 To samo, gdy zechcesz by Git zapomniał o wybranych plikach:
  28
  29  $ git rm ramsch.h archaiczne.c
  30  $ git rm -r obciążający/materiał/
  31
  32 Jeśli sam tego jeszcze nie zrobiłeś, to Git usunie pliki za ciebie.
  33
  34 Zmiana nazwy pliku, to to samo co jego skasowanie i ponowne utworzenie z nowa nazwa. Git wykorzystuje do tego skrót *git mv*, który posiada tą samą składnię co polecenie *mv*. Na przykład:
  35
  36  $ git mv bug.c feature.c
  37
  38 === Zaawansowane anulowanie/przywracanie ===
  39
  40 Czasami zechcesz po prostu cofnać się w czasie, zapominając o wszystkich wprowadzonych od tego punktu zmianach. Wtedy:
  41
  42  $ git log
  43
  44 pokaże ci listę dotychczasowych 'commits' i ich kluczy SHA1:
  45
  46 ----------------------------------
  47 commit 766f9881690d240ba334153047649b8b8f11c664 Author: Bob <bob@example.com>
  48 Date: Tue Mar 14 01:59:26 2000 -0800
  49
  50     Ersetzt printf() mit write().
  51
  52 commit 82f5ea346a2e651544956a8653c0f58dc151275c
  53 Author: Alicja <alicja@example.com>
  54 Date: Thu Jan 1 00:00:00 1970 +0000
  55
  56     Initial commit. ----------------------------------
  57
  58 Kilka początkowych znaków klucza SHA1 wystarcza by jednoznacznie zidentyfikować 'commit', alternatywnie możesz skopiować i wkleić cały klucz. Wpisując:
  59
  60  $ git reset --hard 766f
  61
  62 przywrócisz stan do stanu podanego 'commit', a wszystkie poźniejsze zmiany zostaną bezpowrotnie skasowane.
  63
  64 Innym razem chcesz tylko na moment przejść do jednego z poprzednich stanów. W tym wypadku użyj komendy:
  65
  66  $ git checkout 82f5
  67
  68 Tym poleceniem wrócisz się w czasie zachowując nowsze zmiany. Ale, tak samo jak w podróżach w czasie z filmaów science-fiction - jeśli teraz dokonasz zmian i zapamietsz je poleceniem 'commit', zostaniesz przeniesiona do alternatywnej rzeczywostosci, ponieważ twoje zmiany różnią się od dokonanych w późniejszych punktach czasu.
  69
  70 Tą alternatywną rzeczywistość nazywamy 'branch', a <<branch,zajmiemy się tym w późniejszym czasie>>. Na razie, zapamietaj tylko, że:
  71
  72  $ git checkout master
  73
  74 sprowadzi cię znów do teraźniejszości. Również, aby uprzedzić narzekanie Gita, powinieneś przed każdym 'checkout' wykonać 'commit' lub 'reset'.
  75
  76 Korzystając ponownie z analogii do gier komputerkowych:
  77
  78 - *`git reset --hard`*: załadój jakiś starszy stan gry i skasuj wszystkie nowsze niż właśnie ładowany.
  79
  80 - *`git checkout`*:  Załadój stary stan, grając dalej, twój stan będzie się różnił od nowszych zapamietanych. Każdy stan, który zapamiętasz od teraz, powstanie w osobnym 'branch', reprezentującym alternatywną rzeczywitość. <<branch, Wrócimy do tego później>>
  81
  82 Jeśli chcesz, możesz przywrócić jedynie wybrane pliki lub katalogi poprzez dodanie ich nazw do polecenia
  83
  84  $ git checkout 82f5 jeden.plik inny.plik
  85
  86 Bądź ostrożny, ten sposób użycia komendy *checkout* może bez uprzedzenia skasować pliki. Aby zabezpieczyć sie przed takimi wypadkami powinieneś zawsze wykonać polecenie 'commit' zanim wykonasz 'checkout', szczególnie w okresie poznawania Gita. Jeśli czujesz się niepewnie przed wykonaniem jakiejś operacji Gita, generalną zasadą powinno stać sie dla ciebie uprzednie wykonanie *git commit -a*.
  87
  88 Nie lubisz kopiować i wklejać kluczy SHA1? Możesz w tym wypadku skorzystać z:
  89
  90  $ git checkout :/"Mój pierwszy c"
  91
  92 by przenieś się do 'commit', którego opis rozpoczyna zawartą wiadomość. Możesz również cofnąć się do piątego z ostatnio zapamiętanych 'commit':
  93
  94 $ git checkout master~5
  95
  96 === Przywracanie ===
  97
  98 W sali sądowej pewne zdarzenia mogą zostać wykreślone z akt. Podobnie możesze zaznaczyć pewne 'commits' do wykreślenia.
  99
 100  $ git commit -a
 101  $ git revert 1b6d
 102
 103 To polecenie wymaże 'commit' o wybranym kluczu. ten rewers zostanie zapamiętany jako nowy 'commit', co można sprawdzić poleceniem *git log*.
 104
 105 === Generowanie listy zmian ===
 106
 107 Niektóre projekty wymagają http://en.wikipedia.org/wiki/Changelog[pliku changelog]. Wygenerujesz go poleceniem:
 108
 109  $ git log > Changelog
 110
 111 === Ładowanie plików ===
 112
 113 Kopię projektu zarządzanego za pomocą Gita uzyskasz poleceniem:
 114
 115  $ git clone git://ścieżka/do/projektu
 116
 117 By na przykład zładować wszystkie dane, których urzyłem do stworzenia tej strony skorzystaj z:
 118
 119  $ git clone git://git.or.cz/gitmagic.git
 120
 121 Do polecenia 'clone' wrócimy niebawem.
 122
 123 === Najnowszy stan ===
 124
 125 Jeśli posiadasz już kopię projektu wykonaną za pomocą *git clone*, możesz ją zaktualizować poleceniem:
 126
 127  $ git pull
 128
 129 === Szybka publikacja ===
 130
 131 Przypóśćmy, że napisałeś skrypt i chcesz go udostępnić innym. Mogłabyś poprosić ich, by zładowali go bezpośrednio z twojego komputera. Jeśli jednak zrobią podczas gdy gdy ty wprowadzasz poprawki lub eksperymentujesz ze zmianami, mogłabyś przysporzyć im nieprzyjemności. Z tego powodu istnieje coś takiego jak cykl wydawniczy. Programiści regularnie pracują nad projektem, upubliczniają kod jednak dopiero, jeśli uznają, że nadaje sie już do pokazania.
 132
 133 Aby wykonać to za pomocą GIT, wejdź do katalogu w którym znajduje się twój skrypt:
 134
 135  $ git init
 136  $ git add .
 137  $ git commit -m "Pierwsze wydanie"
 138
 139 Następnie poproś twych użytkowników o wykonanie:
 140
 141  $ git clone twój.komputer:/ścieżka/do/skryptu
 142
 143 by zładować twój skrypt. Zakładamy tu posiadanie przez nich klucza SSH do twojego komputera. Jeśli go nie mają, uruchom *git daemon* i podaj im następujący link:
 144
 145  $ git clone git://twój.komputer/ścieżka/do/skryptu
 146
 147 Od teraz, zawsze gdy uznasz, że wersja nadaje sie do opublikowania, wykonaj polecenie:
 148
 149  $ git commit -a -m "Następna wersja"
 150
 151 a twoi użytkownicy, po wejściu do katalogu zawierającym twój skrypt, będą go mogli zaktualizować poprzez:
 152
 153  $ git pull
 154
 155 Twoi użytkownicy nigdy nie wejdą w posiadanie wersji, których nie chcesz im udostępniać.
 156
 157 === A co robiłem ostatnio? ===
 158
 159 Jeśli chcesz zobaczyć zmiany, które wprowadziłeś of ostatniego 'commit', wpisz:
 160
 161  $ git diff
 162
 163 Albo tylko zmiany od wczoraj:
 164
 165  $ git diff "@{yesterday}"
 166
 167 Albo miedzy określoną wersją i dwoma poprzedzającymi:
 168
 169  $ git diff 1b6d "master~2"
 170
 171 Za każdym razem uzyskane informacje są równocześnie patchem, który poprzez *git apply* może zostac być zastosowany. Spróbuj również:
 172
 173  $ git whatchanged --since="2 weeks ago"
 174
 175 Jeśli chcę sprawdzić listę zmian jakiegoś repozytorium, często korzystam czesto z  http://sourceforge.net/projects/qgit[qgit], ze względu na jego fotogeniczny interfejs, albo z http://jonas.nitro.dk/tig/[tig], tekstowy interfejs, działający zadowalająco gdy mamy do czynienia z wolnym łączem internetowym. Alternatywnie, zainstaluj serwer http, uruchom *git instaweb*, i odpal dowolną przeglądarkę internetową.
 176
 177 === Ćwiczenie ===
 178
 179 Niech A, B, C i D będą 4 nastepujacymi po sobie 'commits', gdzie B różni sie od A, jedynie tym, iż usunieto kilka plikow. Chcemy teraz te usuniete pliki zrekonstruowac do D. Jak to można zrobić?
 180
 181 Istnieją przynajmniej 3 rozwiązania. Załóżmm że znajdujemy się obecnie w D:
 182
 183 1. Różnica pomiędzy A i B, to skasowane pliki. Możemy utworzyc patch, który pokaże te różnice i nastepnie zastosować go:
 184
 185  $ git diff B A | git apply
 186
 187 2. Ponieważ pliki zostaly już raz zapamietane w A, możemy je przywrócić:
 188
 189  $ git checkout A foo.c bar.h
 190
 191 3. Możemy też widzieć przejście z A na B jako zmianę, którą można zrewertować:
 192
 193  $ git revert B
 194
 195 A które z tych rozwiązań jest najlepsze? To, które najbardziej tobie odpowiada. Korzystając z Git łatwo osiągnąć cel, czasami prowadzi do niego wiele dróg.