pl/omegat-tmp/target/clone.txt

   1 == Polecenie CLONEN ==
   2
   3 W starszych systemach zarządzania wersją polecenie CHECKOUT stanowi standardową operacje pozyskania danych. Otrzymasz całą masę plików konkretnego stanu
   4
   5 W GIT i innych dzielonych systemach zarządzania wersją to CLONE jest standardem. By pozyskać dane, tworzysz klon całej REPOSITORY. Lub inaczej mówiąc, odzwierciedlasz zentralny server. Wszystko, co można zwobić z centralnym REPOSITORY, możesz również zrobić z klonem.
   6
   7 === Synchronizacja komputera ===
   8
   9 Można zaakceptować, dla ochrony danych i prostej synchonizacji, pracę z archiwami TARBALL albo *rscnc*. Jednak czasami pracuję na laptopie, później na desktopie, w międzyczasie nie nastąpiła miedzy nimi synchronizacja
  10
  11 Utwóż GIT REPOSITORY i COMMITE twoje dane na komputerze. Potem na następnym:
  12
  13 $ git clone anderer.computer:/pfad/zu/dateien
  14
  15 by uzyskać drugą kopie danych i utworzyć GIT REPOSITORY. Od teraz poleceniem:
  16
  17 $ git commit -a $ git pull anderer.computer:/pfad/zu/dateien HEAD
  18
  19 przenosisz stan drugiego komputera na komputer na którym właśnie pracujesz Jeśli dokonałeś zmian na tej samej danej na obydwóch komputerach, GIT cię o tym poinformuje, po usunięciu konfliktu musidz ponownie COMMITEN
  20
  21 === Klasyczne zarządzanie kodem źródłowym ===
  22
  23 Utwóż GIT REPOSITORY dla twoich danych
  24
  25   $ git commit -m "Erster Commit"
  26
  27 Na centralnym serwerze utwóż tzw BARE REPOSITORY w jakimkolwiek katalogu
  28
  29 $ mkdir proj.git $ cd proj.git $ git init --bare $ touch proj.git/git-daemon-export-ok
  30
  31 Jeśli konieczne, wystartuj GIT-DAEMON
  32
  33 $ git daemon --detach # er könnte schon laufen
  34
  35 Jeśli korzystasz z hosting to poszukaj wskazówek utwożemia najpierw pustego REPOSITORY Zwykle konieczne jest wypełnienie formulaża online na stronie internetowej usługodawcy
  36
  37 Przenieś (PUSH) twój projekt teraz na centralny serwer:
  38
  39 $ git push zentraler.server/pfad/zu/proj.git HEAD
  40
  41 By pozyskać kod źródłowy programista podaje zwykle polecenie tego rodzaju:
  42
  43 $ git clone zentraler.server/pfad/zu/proj.git
  44
  45 Po dokonaniu edycji programista zapamiętuje zmiany lokalnie:
  46
  47 $ git commit -a
  48
  49 Aby zaktualizować do wersji na serwerze:
  50
  51 $ git pull
  52
  53 Jeżli wystąpią jakiekolwiek konflikty MERGE, powinny być usunięte in na nowo COMMIT
  54
  55 $ git commit -a
  56
  57 Lokalne zmiany przekazujemy do serwera poleceniem:
  58
  59 $ git push
  60
  61 Jeśli w międzyczasie nastąpiły nowe zmiany na serwerze wprowadzone przez innego programistę, twój PUSH nie powiedzie sie. Zaktualizuj lokalne REPOSITORY ponownie poleceniem PULL, pozbądź się konfliktów i spróbuj jeszcze raz
  62
  63 Programiści potrzebują dostęp SSH by móc wykonać polecenia PULL i PUSH. Mimo to każdy może otrzymać kod źródłowy poprzez podanie:
  64
  65 $ git clone git://zentraler.server/pfad/zu/proj.git
  66
  67 Protokół GIT przypomina HTTP: nie posiada autentyfikacji, więc każdy może zładować dane. Przy ustawieniach standardowych polecenie PUSH za pomocą protokołu GIT jest zdeaktywowane.
  68
  69 === Utajnione Zródła ===
  70
  71 Przy projektach Closed-Source nie używaj polecenia TOUCH i upewnij się, że nigdy nie zostanie utworzony plik o nazwie git-daemon-export-ok To REPOSITORY nie może komunikować sie poprzez protokół GIT, tylko posiadający dostęp przez SSH mogą widzieć dane. Jeśli wszystkie REPOSITORIES są zamknięte, nie ma potrzeby startować deamon GIT, ponieważ cała komunikacja odbywa się za pomocą SSH.
  72
  73 === Gołe REPOSITORIES ===
  74
  75 Gołe (BARE) REPOSITORY jest tak nazywane, ponieważ nie posiada katalogu roboczego Posiada jedynie dane, które są zwykle schowane w podkatalogu .git. Innymi słowami, zarządza historią projektum, nie otrzymuje jednak nigdy jakiejkolwiek wersji
  76
  77 BARE REPOSITORY przejmuje rolę głównego serwera w scentralizowanych systemach kontroli wersi: dom trojego projektu Programiści klonują twój projekt stamtąd i PUSHEN ostatnie oficjalne zmiany na niego. Często znajduje się ono na serwerze, który nie robi dużo więcej, niż rozdzielanie danych. Sama praca dzieje się w klonach projektu, w ten sposób domowe-REPOSITORY daje sobie radę nie korzystając z katalogu roboczego
  78
  79 Wiele z poleceń GIT nie funkcjonuje na BARE REPOSITORIACH Jedynie w wypadku gdy zmienna systemowa GIT_DIR  ustawiona zostanie na katalog roboczy albo  opcja --bare zostanie przekazana.
  80
  81 === PUSH albo PULL ===
  82
  83 Dlaczego wprowadziliśmy polecenie PUSH, i nie pozostaliśmy przy znanym nam już PULL? Po pierwsze, ponieważ PULL nie działa z BARE REPOSITORIES: zamiast niego używaj FETCH, polecenie którym zajmiemy się później. Również gdybyśmy nawet używali normalnego REPOSITORY na serwerze centralnym, polecenie PULL stanowiłoby żmudną sprawę.  Musielibyśmy najpierw zalogować się na serwerze i poleceniu PULL przekazać adres IP komputera z którego chcemy sciągnąć pliki. Mogłyby nam stanąć na przeszkodzie firewalls, nie wspominając już o braku uprawnień do konsoli.
  84
  85 W każdymbądź razie, odradzamy z korzystania z polecenia PUSH do REPOSITORY Jeśli cel posiadałny katalog roboczy, mogłyby powstać nieścisłości.
  86
  87 Krótko mówiąc, podczas gdy uczysz się korzystania z GIR, korzystaj z polecenia PUSH tylko, gdy cel jest BARE REPOSITORY, w wszystkich innych wypadkach z polecenia PULL
  88
  89 === FORK projektu ===
  90
  91 Jeśli nie masz już ochoty patrzeć na kierunek rozwoju w którym poszedł projekt Uważasz, że potrafisz to lepiej To po prostu zwób coś takiego na twoim serwerze:
  92
  93 $ git clone git://haupt.server/pfad/zu/dateien
  94
  95 No i poinformuj wszystkich o twoim fork projektu na twoim serwerze.
  96
  97 W każdej późniejszej chwili możesz zmiany oryginalnego projektu MERGEN poprzez:
  98
  99 $ git pull
 100
 101 === Ultymatywny backup danych ===
 102
 103 Chcesz posiadać liczne, wolne od manipulacji, redudante kopie bezpieczeństwa w różnych miejscach Jeśli projekt posiada wielu programistów, nie musisz niczego robić Ponieważ każdy klon twojego kodu jest pełnowartościową kopią bezpieczeństwa Nie tylko jedo aktualny stan, lecz również jego całą historię. Gdy jakikolwiek klon zostanie uszkodzony, dzięki kryptograficznemu hashowaniu, zostanie to natychmiast rozpoznane, jeśli tylko osoba ta będzie próbować komunikować się z innymi.
 104
 105 Jeśli twój projekt nie jest zbyt mocno znany, spróbuj pozyskać tak wiele serwerów ile to możliwe, by umieścić tam klon
 106
 107 Ci najbardziej paranoidalni powinni zawsze zapisać 20 bajtów SHA1 hash z HEAD i przechowywać na bezpiecznym miejscu Musi być bezpieczne, jednak nie musi być prywatne Na przykład można opublikować go w gazecie, ponieważ byłoby dość trudnym zadaniem zmanipulować każdą kopię gazety
 108
 109 === Multitasking z prędkością światła ===
 110
 111 Załóżmy, że chcesz pracować równocześnie nad wieloma funkcjami Wtedy COMMIT twój projekt i wykomaj:
 112
 113 $ git clone . /irgendein/neuer/ordner
 114
 115 Twardym linkom możemy podziękować, że lokalny klon potrzebuje dużo mniej czasu i pamięci niż zwykły backupq
 116
 117 Możesz pracować nad dwoma funkcjami jednocześnie Na przykład możesz pracować nad klonem, podczas gdy drugi jest kompilowany W każdym momencie możesz COMMITEN i zmiany innego klonu PULLEN
 118
 119 $ git pull /der/andere/clone HEAD
 120
 121 === Zarządzanie wersją w poddziemiu ===
 122
 123 Pracujesz nad projektem, który używa innego systemu kontroli wersji i tęsknisz za GIT? Utwórz GIT REPOSITORY w katalogu roboczym
 124
 125   $ git commit -m "Erster Commit"
 126
 127 następnie sklonuj go:
 128
 129 $ git clone . /irgendein/neuer/ordner
 130
 131 Przejdź teraz do nowego katalogu i pracuj według upodobania. Kiedyś zechcesz zsynchronizować pracę, idź więc do orginalnego katakogu zaktualizuj go najpierw z tym innym systemem kontroli wersji i wpisz:
 132
 133 $ git add . $ git commit -m "Synchronisation mit den anderen"
 134
 135 Następnie przejdź do dowego katalogu i podaj:
 136
 137 $ git commit -a -m "Beschreibung der Änderungen" $ git pull
 138
 139 Sposób w jaki przekaższ zmiany drugiemu systemowi zależy już od niego. Twoj nowy katalog posiada dane z przez ciebie wprowadzonymi zmianami Wykonaj konieczne kroki opisane w innym systemie, by przekazać dane do centralnego składu.
 140
 141 Subversion, być może najlepszy z centralnych systemów, stosowany jest w wielu projektach. Der *git svn*-Befehl automatisiert den zuvor genannten Ablauf für Subversion 'Repositories' und kann auch benutzt werden um http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[ein Git Projekt in ein Subversion 'Repository' zu exportieren].
 142
 143 === Mercurial ===
 144
 145 Mercurial to podobny system kontroli wersji, który prawie bezproblemowo potrafi pracować z GIT Korzystając z rozszerzenia hg-git użytkownik Mercurial jest w stanie prawie bez większych strat PUSH i PULL ze składem GIT.
 146
 147 Sciągnij sobie rozszerzenie hg-git za pomocą GIT:
 148
 149 $ git clone git://github.com/schacon/hg-git.git
 150
 151 albo Mercurial:
 152
 153 $ hg clone http://bitbucket.org/durin42/hg-git/
 154
 155 Niestety nie są mi znane takie rozszerzenia dla GIT. Dlatego jestem za używaniem GIT jako centralnegoo składu, nawet gdy preferujesz Mercurial W projektach prowadzonych za pomocą Mercurial często znajdziemy woluntariusza, który równolegle prowadzi skład GIT, do którego za pomocą rozszerzenia hg-git, synchronizowany jest automatycznie z użytkownikami GIT
 156
 157 To rozszerzenie potrafi również zmienić skład Mercurial w skład GIT, za pomocą komendy PUSH do pustego składu GIT Jeszcze łatwiej dokonamy tego skryptem hg-fast-export.sh, który możemy tu znaleźć:
 158
 159 $ git clone git://repo.or.cz/fast-export.git
 160
 161 Aby przekonwertować wejść do pustego katalogu:
 162
 163 $ git init $ hg-fast-export.sh -r /hg/repo
 164
 165 po uprzednim dodaniu skryptu do `$ PATH`.
 166
 167 === Bazaar ===
 168
 169 Wspomnijmy również pokrótce o Bazaar, ponieważ jest to najbardziej popularny darmowy rozproszony system kontroli wersji po Git i Mercurial.
 170
 171 Bazar ponieważ jest to stosunkowo młody, posiada zaletę perspektywy czasu; jego twórcy mogli uczyć się na błędach z przeszłości i uniknąć historycznych naleciałości. Pozatem programiści byli świadomi popularności i wagi interakcji z innymi systemami kontroli wersji.
 172
 173 Rozszerzenie `Bzr-git` pozwala użytkownikom Bazar dość łatwo pracować z repozytoriami Git  Program `tailor` konwertuje składy Bazaar do składów Git i może zrobić na bieżąco, podczas gdy `bzr-fast-export` lepiej nadaje się do jednorazowej konwersji.
 174
 175 === Dlaczego korzystam z GIT ===
 176
 177 Zdecydowałem się pierwotnie do wyboru GIT, ponieważ słyszałem, że jest w stanie zarządzać tak zawiłym i rozległym projektem jak kod źródłowy Linuxa. Nie miałem jeszcze powodu do zmiany. Git służył mi znakomicie i jak na razoiie jeszcze nigdy mnie nie zawiódł. Ponieważ w pierwszej lini pracuje na linuksie, problemy innych platworm nie mają dla mnie znaczenia.
 178
 179 Preferuję również programy C i skrypty bash w opozycji do na przykład Pythona: posiadają mniej zależności, jestem też spragniony szybkiego wykonywania kodu
 180
 181 Myślałem też nad tym, jak można by ulepszyć GIT, poszło nawet tak daleko, że napisałem własną aplikacje podobną do GIT, w celu jednak wyłącznie ćwiczeń akademickich. Nawet gdybym zakończył mój projekt, mimo to pozostałbym przy GIT, bo ulepszenia byłyby zbyt minimalne by uzasadnić zastosowanie odosobnionego systemu.
 182
 183 Oczywiście może się okazać, że twoje potrzeby i oczekiwania są zupełnie inne i być może wygodniej jest tobie z zupełnie innym systemem. Jakby jednak nie spojrzeć, stosując Git nie stanie ci się niz złego.