szl/basic.txt

   1 == Piyrsze szryty ==
   2
   3 Zanim utopisz sie w morzu polecyń Gita, zyrknij nojpiyrw na pora komyndow Gita. Choć som ajnfachowe, to som ważne i sie wnet przidajom. Powiym prowda, jak zaczłech pracować z Git, to przez pora miesiyncy niy potrzebowołech żodnych innych polecyń, kierch byś sam niy znaloz, w tym rozdziale.
   4
   5 === Zicherowanie łobecnego stanu ===
   6
   7 Chcołbyś drapko zabrać sie do roboty? Zrob piyrw zicherung danych twojego roboczego kataloga.
   8
   9  $ git init
  10  $ git add .
  11  $ git commit -m "Mój pierwszy commit"
  12
  13 Jakbyś potym coś spaproł, możesz pujś nazot do piyrwotnyj wersji.
  14
  15  $ git reset --hard
  16
  17 Jakbyś chcioł tyn stan teraz zapamiyntać:
  18
  19  $ git commit -a -m "Mój następny commit"
  20
  21 === Dodanie, kasowanie i zmiana nazwy ===
  22 === Dodanie, kasowanie i zmiynianie nazwy ===
  23
  24 Ta komynda zatrzimo pliki, kiere żeś dodoł za piyrszym razym przy *git add*. A jak mosz jakieś nowe pliki, dej tyż ło tym znać Gitowi.
  25
  26  $ git add readme.txt Dokumentacja
  27
  28 To samo, jak byś chcioł, żeby Git zapomnioł ło jakichś plikach:
  29
  30  $ git rm ramsch.h archaiczne.c
  31  $ git rm -r obciążający/materiał/
  32
  33 Jak byś tego jeszcze som niy zrobił, to Git wyciepnie pliki za ciebie.
  34
  35 Zmiyniynie nazwy plika, to to samo co wyciepanie go i skudzynie nazot pod innom nazwom. Git biere sam skrot *git mv*, kiery mo ta samo składnia co komynda *mv*. Na przikład:
  36
  37  $ git mv bug.c feature.c
  38
  39 === Zaawansowane anulowanie/prziwrocanie ===
  40
  41 Czasym chciołbyś ajnfach ino sie nazot w czasie cofnońć i zapomnieć o zmianach kiere żeś potym wciepoł. Komynda:
  42
  43  $ git log
  44
  45 pokoże ci lista 'commits' i ich sum kontrolnych SHA1:
  46 ----------------------------------
  47 commit 766f9881690d240ba334153047649b8b8f11c664 Author: Bob <bob@example.com>
  48 Date: Tue Mar 14 01:59:26 2000 -0800
  49
  50     Zamień 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
  59 Kilka początkowych znaków klucza SHA1 wystarcza by jednoznacznie zidentyfikować 'commit', alternatywnie możesz skopiować i wkleić cały klucz. Wpisując:
  60
  61  $ git reset --hard 766f
  62
  63 przywrócisz stan do stanu podanego 'commit', a wszystkie późniejsze zmiany zostaną bezpowrotnie skasowane.
  64
  65 Innym razem chcesz tylko na moment przejść do jednego z poprzednich stanów. W tym wypadku użyj komendy:
  66
  67  $ git checkout 82f5
  68
  69 Tym poleceniem wrócisz się w czasie zachowując nowsze zmiany. Ale, tak samo jak w podróżach w czasie z filmów science-fiction - jeśli teraz dokonasz zmian i zapamiętasz je poleceniem 'commit', zostaniesz przeniesiona do alternatywnej rzeczywistości, ponieważ twoje zmiany różnią się od dokonanych w późniejszych punktach czasu.
  70
  71 Tą alternatywną rzeczywistość nazywamy 'branch', a <<branch,zajmiemy się tym w późniejszym czasie>>. Na razie, zapamiętaj tylko, że:
  72
  73  $ git checkout master
  74
  75 sprowadzi cię znów do teraźniejszości. Również, aby uprzedzić narzekanie Gita, powinieneś przed każdym 'checkout' wykonać 'commit' lub 'reset'.
  76
  77 Korzystając ponownie z analogii do gier komputerowych:
  78
  79 - *`git reset --hard`*: załaduj jakiś starszy stan gry i skasuj wszystkie nowsze niż właśnie ładowany.
  80
  81 - *`git checkout`*:  Załaduj stary stan, grając dalej, twój stan będzie się różnił od nowszych zapamiętanych. Każdy stan, który zapamiętasz od teraz, powstanie w osobnym 'branch', reprezentującym alternatywną rzeczywistość. <<branch,Wrócimy do tego później>>
  82
  83 Jeśli chcesz, możesz przywrócić jedynie wybrane pliki lub katalogi poprzez dodanie ich nazw do polecenia
  84
  85  $ git checkout 82f5 jeden.plik inny.plik
  86
  87 Bądź ostrożny, ten sposób użycia komendy *checkout* może bez uprzedzenia skasować pliki. Aby zabezpieczyć eis 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ć się dla ciebie uprzednie wykonanie *git commit -a*.
  88
  89 Nie lubisz kopiować i wklejać kluczy SHA1? Możesz w tym wypadku skorzystać z:
  90
  91  $ git checkout :/"Mój pierwszy c"
  92
  93 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':
  94
  95  $ git checkout master~5
  96
  97 === Przywracanie ===
  98
  99 W sali sądowej pewne zdarzenia mogą zostać wykreślone z akt. Podobnie możesz zaznaczyć pewne 'commits' do wykreślenia.
 100
 101  $ git commit -a
 102  $ git revert 1b6d
 103
 104 To polecenie wymaże 'commit' o wybranym kluczu. ten rewers zostanie zapamiętany jako nowy 'commit', co można sprawdzić poleceniem *git log*.
 105
 106 === Generowanie listy zmian ===
 107
 108 Niektóre projekty wymagają http://en.wikipedia.org/wiki/Changelog[pliku changelog]. Wygenerujesz go poleceniem:
 109
 110  $ git log > Changelog
 111
 112 === Ładowanie plików ===
 113
 114 Kopię projektu zarządzanego za pomocą Gita uzyskasz poleceniem:
 115
 116  $ git clone git://ścieżka/do/projektu
 117
 118 By na przykład zładować wszystkie dane, których użyłem do stworzenia tej strony skorzystaj z:
 119
 120  $ git clone git://git.or.cz/gitmagic.git
 121
 122 Do polecenia 'clone' wrócimy niebawem.
 123
 124 === Najnowszy stan ===
 125
 126 Jeśli posiadasz już kopię projektu wykonaną za pomocą *git clone*, możesz ją zaktualizować poleceniem:
 127
 128  $ git pull
 129
 130 === Szybka publikacja ===
 131
 132 Przypuść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 się już do pokazania.
 133
 134 Aby wykonać to za pomocą GIT, wejdź do katalogu w którym znajduje się twój skrypt:
 135
 136  $ git init
 137  $ git add .
 138  $ git commit -m "Pierwsze wydanie"
 139
 140 Następnie poproś twych użytkowników o wykonanie:
 141
 142  $ git clone twój.komputer:/ścieżka/do/skryptu
 143
 144 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:
 145
 146  $ git clone git://twój.komputer/ścieżka/do/skryptu
 147
 148 Od teraz, zawsze gdy uznasz, że wersja nadaje się do opublikowania, wykonaj polecenie:
 149
 150  $ git commit -a -m "Następna wersja"
 151
 152 a twoi użytkownicy, po wejściu do katalogu zawierającym twój skrypt, będą go mogli zaktualizować poprzez:
 153
 154  $ git pull
 155
 156 Twoi użytkownicy nigdy nie wejdą w posiadanie wersji, których nie chcesz im udostępniać.
 157
 158 === A co robiłem ostatnio? ===
 159
 160 Jeśli chcesz zobaczyć zmiany, które wprowadziłeś of ostatniego 'commit', wpisz:
 161
 162  $ git diff
 163
 164 Albo tylko zmiany od wczoraj:
 165
 166  $ git diff "@{yesterday}"
 167
 168 Albo miedzy określoną wersją i dwoma poprzedzającymi:
 169
 170  $ git diff 1b6d "master~2"
 171
 172 Za każdym razem uzyskane informacje są równocześnie patchem, który poprzez *git apply* może zostać być zastosowany. Spróbuj również:
 173
 174  $ git whatchanged --since="2 weeks ago"
 175
 176 Jeśli chcę sprawdzić listę zmian jakiegoś repozytorium, często korzystam często 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ą.
 177
 178 === Ćwiczenie ===
 179
 180 Niech A, B, C i D będą 4 następującymi po sobie 'commits', gdzie B różni się od A, jedynie tym, iż usunięto kilka plików. Chcemy teraz te usunięte pliki zrekonstruować do D. Jak to można zrobić?
 181
 182 Istnieją przynajmniej 3 rozwiązania. Załóżmy że znajdujemy się obecnie w D:
 183
 184 1. Różnica pomiędzy A i B, to skasowane pliki. Możemy utworzyć patch, który pokaże te różnice i następnie zastosować go:
 185
 186  $ git diff B A | git apply
 187
 188 2. Ponieważ pliki zostały już raz zapamiętane w A, możemy je przywrócić:
 189
 190  $ git checkout A foo.c bar.h
 191
 192 3. Możemy też widzieć przejście z A na B jako zmianę, którą można zrewertować:
 193
 194  $ git revert B
 195
 196 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.