pl/omegat-tmp/target/basic.txt

   1 == Pierwsze kroki ==
   2
   3 Zanim zmoczymy nogi w morzu polecen GIT, przyjrzyjmy sie kilku prostym poleceniom Momo ich prostoty, wszystkie sa wazne i pozyteczne. Bedac szczery, przez pierwsze miesiace pracy z GIT nie potrzebowalem zadnych innych, niz opisanych w tym rozdziale
   4
   5 === Backup ===
   6
   7 Masz zamiar dokonania wielu zmian? Nie ma sprawy, jednak najpierw zabezpiecz dane.
   8
   9   $ git commit -m "Meine erste Sicherung"
  10
  11 Jesli cokolwiek staloby sie podczas wprowadzania zmian, mozesz przywrocic stara wersje
  12
  13 $ git reset --hard
  14
  15 Aby zapisac nowy stan:
  16
  17 $ git commit -a -m "Eine andere Sicherung"
  18
  19 === Dodac, skasowac, zmienic nazwe ===
  20
  21 Do tej pory git zajal sie jedynie plikami, ktore juz istnialy podczas gdy wykonales poraz pierwszy polecenie *git add* Jesli dodales nowe pliki, musisz o tym poinformowac GIT
  22
  23 $ git add readme.txt Dokumentation
  24
  25 To samo, gdy chcesz by GIT zapomnial o plikach:
  26
  27 $ git rm ramsch.h veraltet.c $ git rm -r belastendes/material/
  28
  29 GIT usunie dane za ciebie, jesli tego jeszcze nie zrobiles.
  30
  31 Zmienic nazwe pliku, to to samo co jego skasowanie  ponowne utworzenie z nowa nazwa. GIT korzysta tu ze skrotu *git mv*, ktory posiada ten sam syntax co polecenie *mv* Na przyklad:
  32
  33 $ git mv fehler.c feature.c
  34
  35 === Zaawansowane usuwanie/przywracanie ===
  36
  37 Czasami zechcesz po prostu cofnac sie w czasie i zapomniec o wszystkich zmianach ktorych dokonales Wtedy:
  38
  39 $ git log
  40
  41 pokaze ci liste dotychczasowych 'commits' i ich SHA1-hash:
  42
  43 ---------------------------------- commit 766f9881690d240ba334153047649b8b8f11c664 Author: Bob <bob@example.com> Date: Tue Mar 14 01:59:26 2000 -0800
  44
  45 Ersetze printf() mit write().
  46
  47 commit 82f5ea346a2e651544956a8653c0f58dc151275c Author: Alice <alice@example.com> Date: Thu Jan 1 00:00:00 1970 +0000
  48
  49 Initial commit. ----------------------------------
  50
  51 Pierwsze kilka znakow hash wystarcza by jednoznacznie zidentyfikowac 'commit'; alternatywnie mozesz wkopiowac caly hash. Za pomoc
  52
  53 $ git reset --hard 766f
  54
  55 możesz przywrócic stan wybranego commit i wszystkie poźniejsze zmiany bezpowrotnie skasować.
  56
  57 Innym razem chcesz tylko na moment przejść do jednedo z poprzednich stanów. W tym wypadku użyj komendy:
  58
  59 $ git checkout 82f5
  60
  61 Tym poleceniem wrócisz się w czasie zachowując jednak nowsze zmiany. Ale, tak samo jak w filmach science-fiction o podróżach w czasie, jeśli teraz dokonasz zmian i zapamietsz je poleceniem commit, przeniesiesz się do innej rzeczywostosci, ponieważ twoje zmiany różnią sie od dokonanych wcześniej.
  62
  63 Ta inna rzeczywistość, to tzw. branch <<branch, zajmiemy się tym w późniejszym czasie>>. zapamietaj jednak na razie, że:
  64
  65 $ git checkout master
  66
  67 sprowadzi cie znów do teraźniejszości. Aby zapobiec by GIT sie stawiał, powinieneś przed każdym CHECKOUT wszystkie zmiany COMMITEN albo RESETEN
  68
  69 Jeśli znów skorzystamy z analogii do gier komputerkowych:
  70
  71 - *`git reset --hard`*:  załadój poprzedni stan i skasuj wszystkie stany które są nowsze niż teraz załadowany.
  72
  73 - *`git checkout`*:  Załadój stary stan, ale jeśli będziesz grał dalej, twój stan będzie się różnił od poprzednio zapamietanych. Każdy stan, który od teraz zostanie zapamiętany, powstanie w osobnym BRANCH, który odpowiada alternatywnej rzeczywitości. <<branch, wrócimy do tego później>>
  74
  75 Jeśłi chcesz, możesz przywołać jedynie wybrane pliki lub katalogi poprzez dodanie ich nazw do polecenia
  76
  77 $ git checkout 82f5 eine.datei andere.datei
  78
  79 Bądź ostrożny, ten sposób wykonania komendy CHECKOUT może skasować pliki bez poinformowania o tym. Aby zabezpieczyc sie przed takimi wypadkami powinieneś zawsze wykonać polecenie COMMIT zanim wykonasz CHECKOUT, szczególnie ucząc się jeszcze pracy z GIT, Ogólnia zasadą powinno być, że gdy nie jesteś pewien, obojętnie czy to jest polecenie GIT czy jakakolwiek inna operacja. wykonaj zawsze *git commit -a*.
  80
  81 Nie lubisz kopiować i wklejać hash-ów? Możesz w tym wypadku skorzystać z:
  82
  83 $ git checkout :/"Meine erste Si"
  84
  85 by przenieś się do COMMIT, którego opis właśnie tak sie rozpoczyna, Możesz również udać się do 5 z ostatnich COMMIT:
  86
  87 $ git checkout master~5
  88
  89 === Przywracanie ===
  90
  91 W sali sądowej można pewne zdarzenia wykreślić z  akt. Podobnie możesze celowo wykasować wybrane COMMITS.
  92
  93 $ git commit -a $ git revert 1b6d
  94
  95 To polecenie skasuje COMMIT o wybranym hash-u. To wycofanie zostanie zapamiętane jako nowy COMMIT, co można sprawdzić poleceniem *git log*.
  96
  97 === Utwożenie historii ===
  98
  99 Niektóre projekty wymagają pliku historii zmian Możesz go utwoszyć korzystając z polecenia:
 100
 101 $ git log > ChangeLog
 102
 103 === Zładowanie danych ===
 104
 105 Kopię projektu zarządzanego za pomocą GIT uzyskasz poleceniem:
 106
 107 $ git clone git://server/pfad/zu/dateien
 108
 109 By na przykład zładować wszystkie dane, których urzyłem do stworzenia tej strony skorzystaj z:
 110
 111 $ git clone git://git.or.cz/gitmagic.git
 112
 113 O poleceniu CLONE można przytoczyć jeszcze wiele innych wątków.
 114
 115 === Najnowsze z nowych ===
 116
 117 Jeśli posiadasz już kopię projektu, możesz ją zaktualizować poleceniem:
 118
 119 $ git pull
 120
 121 === Uproszczone publikowanie ===
 122
 123 Załóżmy, że napisałeś skrypt i chcesz go udostępnić innym. Móglbyś ich po prostu poprosić, by zładowali go po prostu bezpośrednio z twojego komputera, ale jeśli to zrobią podczas gdy ty eksperymentujesz czy poprawiasz pracę nad skryptem, mogliby wpaść w tarapaty. Właśnie dla tego istnieje coś takiego jak RELEASEZYKLEN. Programiści regularnie pracują nad projektem, upubliczniają kod jednak dopiero, jeśli uznają, że nadaje sie do pokazania.
 124
 125 Aby wykonać to za pomocą GIT, wejdź do katalogu w którym znajduje się twój skrypt:
 126
 127   $ git commit -m "Erster Stand"
 128
 129 Następnie udostępnij link twoim użytkownikom:
 130
 131 $ git clone dein.computer:/pfad/zum/skript
 132
 133 by mogli zładować skrypt. Wymaga to od nich posiadanie klucza SSH do twojego komputera. Jeśli nie mają go, wykonaj *git daemon* i podaj im następujący link:
 134
 135 $ git clone git://dein.computer/pfad/zum/skript
 136
 137 Od teraz, zawsze gdy uznasz, że twój skrypt nadaje sie do opublikowania, wykonaj polecenie:
 138
 139 $ git commit -a -m "Nächster Stand"
 140
 141 a twoji uzytkownicy beda mogli zaktualisowac go poprzez:
 142
 143 $ git pull
 144
 145 Twoi uzytkownicy nigdy nie wejda w posiadanie wersji, ktorych nie chcesz by posiadali Oczywiscie ten trick funkcjonuje ze wszystkim, nie tylko ze skryptami
 146
 147 === Co ostatnio robilem? ===
 148
 149 Znajdz co zrobiles od ostatniego COMMIT:
 150
 151 $ git diff
 152
 153 Albo od wczoraj
 154
 155 $ git diff "@{gestern}"
 156
 157 Albo miedzy jakakolwiek wersja a przedostatnia:
 158
 159 $ git diff 1b6d "master~2"
 160
 161 Za kazdym razem uzyskane informacje sa PATCH ktory poprzez *git applly* moze zostac wgrany Sprobuj rowniez:
 162
 163 $ git whatchanged --since="2 weeks ago"
 164
 165 Jesli chce sprawdzic historie jakiegos REPOSITORY korzystam czesto z  XXXX, poniewaz posiada przyjazny interfejs uzytkownika, albo  XXXX, program konsolowy, ktory bardzo dobrze dziala jesli mamy do czynienia z powolnymi laczami interenetowymi. Alternatywnie mozesz zaiinstalowac serwer http za pomoca *git instaweb*, wtedy mozesz przegladac kazda przegladarka.
 166
 167 === Cwiczenie ===
 168
 169 A, B, C i D sa 4 nastepujacymi po sobie COMMITS. B rozni sie od A, jedynie tym, ze usunieto kilka plikow. Chcemy teraz te usuniete pliki zrekonstruowac w D, a nie w B. Jak to zrobic?
 170
 171 Istnieja przynajmniej 3 rozwiazania. Zalozmym ze jestesmy w D:
 172
 173 1. Roznica miedzy A i B, to skasowane pliki. Mozemy utworzyc PATCH, ktory pokaze te roznice i nastepnie zastosowac go na D
 174
 175 $ git diff B A | git apply
 176
 177 2. Poniewaz dane zostaly zapamietane w COMMIT A, mozemy je przywrocic
 178
 179 $ git checkout A foo.c bar.h
 180
 181 3. Mozemy rowniez COMMIT A na B widziec jako zmiane, ktora mozemy przywrocic
 182
 183 $ git revert B
 184
 185 Ktore rozwiazanie jest najlepsze? To, ktore najbardziej tobie odpowiada. Korzystajac z GIT latwo mozna osiagnac cel, czasami prowadza do niego rozne drogi.