diff --git a/.gitignore b/.gitignore index 88ac88c5..26cf1373 100644 --- a/.gitignore +++ b/.gitignore @@ -9,3 +9,4 @@ fop-zh* /fop/* .* *~ +.Rproj.user diff --git a/Makefile b/Makefile index 66e22fb2..0bcd1687 100644 --- a/Makefile +++ b/Makefile @@ -1,16 +1,14 @@ # The availaible translation languages. # When starting a new translation, add a language code here. -# TRANSLATIONS = de es fr ko pt_br ru uk vi zh_cn zh_tw it pl LANGS = en $(TRANSLATIONS) -SHELL := /bin/bash -.PHONY: all clean sync public distclean $(LANGS) +.PHONY: all clean $(LANGS) all: $(LANGS) -$(LANGS): %: book-% book-%/default.css book-%.html book-%.pdf +$(LANGS): %: book-% book-%/default.css book-%.html book-%.pdf book-%.epub # The book consists of these text files in the following order: @@ -57,27 +55,29 @@ $(foreach l,$(LANGS),book-$(l)/default.css): book-%/default.css: book.css rsync book.css book-$*/default.css $(foreach l,$(LANGS),book-$(l).html): book-%.html: book-%.xml - xmlto -m custom-nochunks.xsl html-nochunks $^ - -tidy -utf8 -imq $@ + pandoc -s -f docbook -t html5 -o $@ $^ -# Set SP_ENCODING to avoid "non SGML character" errors. -# Can also do SP_ENCODING="UTF-8". $(foreach l,$(LANGS),book-$(l).pdf): book-%.pdf: book-%.xml - if [ $* = zh_cn -o $* = zh_tw ]; then \ - if ! [ -f fop-$*.xsl ]; then wget -q http://bestrecords.net/fop/fop-$*.xsl; fi; \ - if ! [ -f fop-$*.xconf ]; then wget -q http://bestrecords.net/fop/fop-$*.xconf; fi; \ - xmlto -m fop-$*.xsl --with-fop -p "-c `pwd`/fop-$*.xconf" pdf book-$*.xml ;\ - elif [ $* = vi ] ; then \ - xsltproc --encoding utf-8 fop-vi.xsl book-$*.xml > book-$*.fo; \ - fop -c fop-vi.xconf -fo book-$*.fo -pdf book-$*.pdf; \ - else \ - SP_ENCODING="XML" docbook2pdf book-$*.xml; \ - fi + pandoc -s -f docbook -o $@ --pdf-engine=xelatex $^ + +book-ru.pdf: book-ru.xml + pandoc -s -f docbook -o $@ --pdf-engine xelatex -V mainfont='DejaVuSansMono' $^ + +book-uk.pdf: book-uk.xml + pandoc -s -f docbook -o $@ --pdf-engine xelatex -V mainfont='DejaVuSansMono' $^ + +book-ko.pdf: book-ko.xml + pandoc -s -f docbook -o $@ --pdf-engine xelatex -V CJKmainfont='NanumGothic' $^ + +book-zh_cn.pdf: book-zh_cn.xml + pandoc -s -f docbook -o $@ --pdf-engine xelatex -V CJKmainfont='WenQuanYi Micro Hei Mono' $^ + +book-zh_tw.pdf: book-zh_tw.xml + pandoc -s -f docbook -o $@ --pdf-engine xelatex -V CJKmainfont='WenQuanYi Micro Hei Mono' $^ + +$(foreach l,$(LANGS),book-$(l).epub): book-%.epub: book-%.xml + pandoc -s -f docbook -o $@ $^ clean: -rm -rf $(foreach l,$(LANGS),book-$(l).pdf book-$(l).xml book-$(l).html book-$(l)) \ *.fo *.log *.out *.aux conf - -distclean: clean - -rm -rfv fop fop-zh* - diff --git a/custom-html.xsl b/custom-html.xsl index 8ca69694..0753e78e 100644 --- a/custom-html.xsl +++ b/custom-html.xsl @@ -15,16 +15,16 @@ - - - + diff --git a/custom-nochunks.xsl b/custom-nochunks.xsl deleted file mode 100644 index 8871c4b4..00000000 --- a/custom-nochunks.xsl +++ /dev/null @@ -1,8 +0,0 @@ - - - - diff --git a/de/branch.txt b/de/branch.txt index ea370d67..43f91622 100644 --- a/de/branch.txt +++ b/de/branch.txt @@ -83,7 +83,7 @@ Was, wenn Du am Ende die temporären Änderungen sichern willst? Einfach: und 'commite', bevor Du auf den 'Master Branch' zurückschaltest. Wann immer Du zu Deiner Schmutzarbeit zurückkehren willst, tippe einfach: - $ git checkout schnmutzig + $ git checkout schmutzig Wir sind mit dieser Anweisung schon in einem früheren Kapitel in Berührung gekommen, als wir das Laden alter Stände besprochen haben. Nun können wir diff --git a/de/drawbacks.txt b/de/drawbacks.txt index 97e6fe57..ad0e5427 100644 --- a/de/drawbacks.txt +++ b/de/drawbacks.txt @@ -24,7 +24,7 @@ Git unter Microsoft Windows kann frustrierend sein: - http://cygwin.com/[Cygwin], eine Linux ähnliche Umgebung für Windows, enthält http://cygwin.com/packages/git/[eine Windows Portierung von Git]. -- http://code.google.com/p/msysgit/[Git unter MSys] ist eine Alternative, +- https://gitforwindows.org/[Git für Windows] ist eine Alternative, die sehr wenig Laufzeitunterstützung erfordert, jedoch bedürfen einige Kommandos noch einer Überarbeitung. diff --git a/de/pot/preface.po b/de/pot/preface.po index f949c5d2..a6d735ec 100644 --- a/de/pot/preface.po +++ b/de/pot/preface.po @@ -85,11 +85,10 @@ msgstr "" #: ../en/preface.txt:22 msgid "" "link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, " -"and Nicolas Deram. Also hosted at http://tutoriels.itaapy.com/[itaapy]." +"and Nicolas Deram." msgstr "" "link:/~blynn/gitmagic/intl/fr/[Französich]: von Alexandre Garel, Paul " -"Gaborit, und Nicolas Deram. Auch gehostet unter http://tutoriels.itaapy.com/" -"[itaapy]." +"Gaborit, und Nicolas Deram." #. type: Bullet: ' - ' #: ../en/preface.txt:22 diff --git a/de/preface.txt b/de/preface.txt index 615a814b..cae8949b 100644 --- a/de/preface.txt +++ b/de/preface.txt @@ -24,8 +24,7 @@ Bedarf zuschneiden kannst. Meng und JiangWei. Zu link:/~blynn/gitmagic/intl/zh_tw/[Traditionellem Chinesisch] konvertiert via +cconv -f UTF8-CN -t UTF8-TW+. - link:/~blynn/gitmagic/intl/fr/[Französich]: von Alexandre Garel, Paul - Gaborit, und Nicolas Deram. Auch gehostet unter - http://tutoriels.itaapy.com/[itaapy]. + Gaborit, und Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[Deutsch]: von Benjamin Bellee und Armin Stebich; Auch gehostet unter http://gitmagic.lordofbikes.de/[Armin's Website]. diff --git a/en/drawbacks.txt b/en/drawbacks.txt index eab26681..f2a8e2c9 100644 --- a/en/drawbacks.txt +++ b/en/drawbacks.txt @@ -18,7 +18,7 @@ Git on Microsoft Windows can be cumbersome: - http://cygwin.com/[Cygwin], a Linux-like environment for Windows, contains http://cygwin.com/packages/git/[a Windows port of Git]. -- http://code.google.com/p/msysgit/[Git on MSys] is an alternative requiring minimal runtime support, though a few of the commands need some work. +- https://gitforwindows.org/[Git for Windows] is an alternative requiring minimal runtime support, though a few of the commands need some work. === Unrelated Files === diff --git a/en/preface.txt b/en/preface.txt index 42bd2df9..904d82df 100644 --- a/en/preface.txt +++ b/en/preface.txt @@ -13,7 +13,7 @@ Rather than go into details, we provide rough instructions for particular effect .Translations - link:/\~blynn/gitmagic/intl/zh_cn/[Simplified Chinese]: by JunJie, Meng and JiangWei. Converted to link:/~blynn/gitmagic/intl/zh_tw/[Traditional Chinese] via +cconv -f UTF8-CN -t UTF8-TW+. - - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, and Nicolas Deram. Also hosted at http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, and Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[German]: by Benjamin Bellee and Armin Stebich; also http://gitmagic.lordofbikes.de/[hosted on Armin's website]. - link:/~blynn/gitmagic/intl/it/[Italian]: by Mattia Rigotti. - link:/~blynn/gitmagic/intl/ko/[Korean]: by Jung-Ho (John) Han; also https://sites.google.com/site/drinkhanjohn/useful-links/[hosted on John's website]. @@ -28,6 +28,7 @@ Rather than go into details, we provide rough instructions for particular effect - link:book.html[Single webpage]: barebones HTML, with no CSS. - link:book.pdf[PDF file]: printer-friendly. + - link:book.epub[EPUB file]: E-reader-friendly. - http://packages.debian.org/gitmagic[Debian package], http://packages.ubuntu.com/gitmagic[Ubuntu package]: get a fast and local copy of this site. Handy http://csdcf.stanford.edu/status/[when this server is offline]. - http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/[Physical book [Amazon.com]]: 64 pages, 15.24cm x 22.86cm, black and white. Handy when there is no electricity. @@ -50,16 +51,16 @@ If I've left you out by mistake, please tell me or just send me a patch! === License === -This guide is released under http://www.gnu.org/licenses/gpl-3.0.html[the GNU General Public License version 3]. Naturally, the source is kept in a Git -repository, and can be obtained by typing: +This guide is released under http://www.gnu.org/licenses/gpl-3.0.html[the GNU General Public License, version 3] or any later version published by the Free Software Foundation. + +Naturally, the source is kept in a Git repository, and can be obtained by +typing: $ git clone git://repo.or.cz/gitmagic.git # Creates "gitmagic" directory. or from one of the mirrors: $ git clone git://github.com/blynn/gitmagic.git - $ git clone git://gitorious.org/gitmagic/mainline.git - $ git clone https://code.google.com/p/gitmagic/ $ git clone git://git.assembla.com/gitmagic.git $ git clone git@bitbucket.org:blynn/gitmagic.git diff --git a/es/drawbacks.txt b/es/drawbacks.txt index 68c67a52..7698b15d 100644 --- a/es/drawbacks.txt +++ b/es/drawbacks.txt @@ -20,7 +20,7 @@ Git en Microsoft Windows puede ser engorroso: - http://cygwin.com/[Cygwin], un ambiente similar a Linux para Windows, contiene http://cygwin.com/packages/git/[una versión de Git para Windows]. -- http://code.google.com/p/msysgit/[Git en MSys] es una alternativa que requiere un soporte mínimo para la ejecución, aunque algunos de los comandos necesitan cierto trabajo. +- https://gitforwindows.org/[Git para Windows] es una alternativa que requiere un soporte mínimo para la ejecución, aunque algunos de los comandos necesitan cierto trabajo. === Archivos No Relacionados === diff --git a/es/preface.txt b/es/preface.txt index ca175be4..1ad9064a 100644 --- a/es/preface.txt +++ b/es/preface.txt @@ -12,7 +12,7 @@ En lugar de ser detallados, proveemos instrucciones generales para efectos parti .Otras ediciones - - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[Traducción al chino]: por JunJie, Meng y JiangWei. + - link:/~blynn/gitmagic/intl/zh_cn/[Traducción al chino]: por JunJie, Meng y JiangWei. - link:book.html[Una única página]: HTML simple, sin CSS. - link:book.pdf[Archivo PDF]: Listo para imprimir. - http://packages.debian.org/search?searchon=names&keywords=gitmagic[Paquete gitmagic para Debian]: Consigue una copia rápida y local de este sitio. http://packages.ubuntu.com/jaunty/gitmagic[Paquete para Ubuntu (Jaunty Jackalope)] también disponible. Útil http://csdcf.stanford.edu/status/[cuando este servidor está offline para mantenimiento]. diff --git a/fop-vi.xconf b/fop-vi.xconf deleted file mode 100644 index 97972ffc..00000000 --- a/fop-vi.xconf +++ /dev/null @@ -1,11 +0,0 @@ - - - - - - /usr/share/fonts/truetype/ttf-dejavu/ - - - - - diff --git a/fop-vi.xsl b/fop-vi.xsl deleted file mode 100644 index 7558fd37..00000000 --- a/fop-vi.xsl +++ /dev/null @@ -1,17 +0,0 @@ - - - - - -DejaVu Serif -DejaVu Sans ExtraLight -DejaVu Serif Bold - - - diff --git a/fr/branch.txt b/fr/branch.txt index 8d047871..1c2e7648 100644 --- a/fr/branch.txt +++ b/fr/branch.txt @@ -297,7 +297,7 @@ tout, des clones sont tout aussi rapides et vous pouvez basculer de l'un à l'autre par un simple *cd* au lieu de commandes Git ésotériques. Considérez les navigateurs Web. Pourquoi proposer plusieurs onglets ainsi que -plusieurs fenêtres ? Parce proposer les deux permet de s'adapter à une large +plusieurs fenêtres ? Parce que proposer les deux permet de s'adapter à une large gamme d'utilisations. Certains préfèrent n'avoir qu'une seule fenêtre avec plein d'onglets. D'autres font tout le contraire : plein de fenêtres avec un seul onglet. D'autres encore mélangent un peu des deux. diff --git a/fr/drawbacks.txt b/fr/drawbacks.txt index d2fd7422..8c06138f 100644 --- a/fr/drawbacks.txt +++ b/fr/drawbacks.txt @@ -11,9 +11,9 @@ main. Avec le temps, les spécialistes de cryptographie découvrent de plus en plus de faiblesses de SHA1. À ce jour, la découverte de collisions d'empreintes semble -à la portée d'organisations bien dotée. Et d'ici quelques années, peut-être que -même un simple PC aura assez de puissance de calcul pour corrompre de manière -indétectable un dépôt Git. +à la portée d'organisations bien dotées. Et d'ici quelques années, peut-être +que même un simple PC aura assez de puissance de calcul pour corrompre de +manière indétectable un dépôt Git. Heureusement Git aura migré vers une fonction de calcul d'empreintes de meilleure qualité avant que de futures recherches détruisent SHA1. @@ -25,7 +25,7 @@ Git sur Microsoft Windows peut être jugé encombrant : - http://cygwin.com/[Cygwin] est un environnement de type Linux dans Windows proposant http://cygwin.com/packages/git/[un portage de Git]. -- http://code.google.com/p/msysgit/[Git on MSys] est un autre choix nécessitant +- https://gitforwindows.org/[Git pour Windows] est un autre choix nécessitant beaucoup moins de place. Néanmoins quelques commandes doivent encore être améliorées. @@ -85,11 +85,11 @@ clone ainsi créé offre des fonctionnalités réduites. Git a été conçu pour être rapide au regard de la taille des changements. Les humains font de petits changement de version en version. Une correction de bug en une ligne ici, une nouvelle fonctionnalité là, un commentaire amendé -ailleurs... Mais si vous fichiers changent radicalement à chaque révision +ailleurs... Mais si vos fichiers changent radicalement à chaque révision alors, à chaque commit, votre historique grossit d'un poids équivalent à celui de votre projet. -Il n'y a rien que puisse faire un système de gestion de versions pour éviter +Il n'y a rien qu'un système de gestion de versions puisse faire pour éviter cela, mais les utilisateurs de Git en souffrent plus puisque chaque clone contient habituellement l'historique complet. diff --git a/fr/grandmaster.txt b/fr/grandmaster.txt index 4ee69c00..6921be64 100644 --- a/fr/grandmaster.txt +++ b/fr/grandmaster.txt @@ -234,7 +234,7 @@ intégrées. Pour passer outre, faites : $ git reset --hard 1b6d *Branch* : la suppression de branches échoue si cela implique la perte de -certains commits. Par forcer la suppression, tapez : +certains commits. Pour forcer la suppression, tapez : $ git branch -D branche_morte # à la place de -d diff --git a/fr/intro.txt b/fr/intro.txt index 3a8fbdf3..d7731ce3 100644 --- a/fr/intro.txt +++ b/fr/intro.txt @@ -32,7 +32,7 @@ versions, vous pouvez l'"Enregistrer Sous..." un nom de fichier différent ou le recopier ailleurs avant de l'enregistrer. Vous pouvez même compresser ces copies pour gagner de l'espace. C'est une forme primitive et laborieuse de gestion de versions. Les jeux vidéo se sont améliorés sur ce point depuis -longtemps pusique la plupart proposent différents emplacements de sauvegarde +longtemps puisque la plupart proposent différents emplacements de sauvegarde automatiquement horodatés. Rendons le problème légèrement plus coriace. Imaginez que vous ayez un ensemble diff --git a/fr/multiplayer.txt b/fr/multiplayer.txt index 63139c91..2a8b388f 100644 --- a/fr/multiplayer.txt +++ b/fr/multiplayer.txt @@ -111,12 +111,12 @@ produit un patch qui peut être collé dans un mail. Dans un dépôt Git, tapez pour appliquer le patch. D'une manière plus formelle, lorsque le nom des auteurs et peut-être leur -signature doit apparaître, générer tous les patches depuis un certain point en +signature doit apparaître, générez tous les patches depuis un certain point en tapant : $ git format-patch 1b6d -Les fichiers résultants peuvent être fournis à *git send-email* ou envoyez à la +Les fichiers résultants peuvent être fournis à *git send-email* ou envoyés à la main. Vous pouvez aussi spécifier un intervalle entre deux commits : $ git format-patch 1b6d..HEAD^^ diff --git a/fr/preface.txt b/fr/preface.txt index 17ced1fd..5be7c8a3 100644 --- a/fr/preface.txt +++ b/fr/preface.txt @@ -23,12 +23,11 @@ recettes pour répondre à vos besoins. .Traductions - - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[Chinois + - link:/~blynn/gitmagic/intl/zh_cn/[Chinois (Simplifié)] : par JunJie, Meng et JiangWei. - link:/~blynn/gitmagic/intl/fr/[Française] : par Alexandre Garel, Paul - Gaborit et Nicolas Deram. Hébergé aussi chez - http://tutoriels.itaapy.com/[itaapy]. + Gaborit et Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[Allemande] : par Benjamin Bellee et Armin Stebich. Hébergé aussi sur http://gitmagic.lordofbikes.de/[le site web diff --git a/fr/translate.txt b/fr/translate.txt index 541e0e2a..0fa387e4 100644 --- a/fr/translate.txt +++ b/fr/translate.txt @@ -15,7 +15,7 @@ http://fr.wikipedia.org/wiki/Klingon%20(langue)[Klingon], vous devriez faire : $ git clone git://repo.or.cz/gitmagic.git $ cd gitmagic - $ mkdir tlh # "tlh" et le code IETF de la langue Klingon. + $ mkdir tlh # "tlh" est le code IETF de la langue Klingon. $ cd tlh $ cp ../en/intro.txt . $ edit intro.txt # Traduire le fichier. diff --git a/gitmagic.Rproj b/gitmagic.Rproj new file mode 100644 index 00000000..756002c3 --- /dev/null +++ b/gitmagic.Rproj @@ -0,0 +1,15 @@ +Version: 1.0 + +RestoreWorkspace: Default +SaveWorkspace: Default +AlwaysSaveHistory: Default + +EnableCodeIndexing: Yes +UseSpacesForTab: Yes +NumSpacesForTab: 5 +Encoding: UTF-8 + +RnwWeave: Sweave +LaTeX: pdfLaTeX + +BuildType: Makefile diff --git a/it/drawbacks.txt b/it/drawbacks.txt index ba381b6c..29f4c280 100644 --- a/it/drawbacks.txt +++ b/it/drawbacks.txt @@ -26,7 +26,7 @@ Git per Microsoft Windows può essere piuttosto ingombrante: Windows che contiene http://cygwin.com/packages/git/[una versione di Git per Windows]. -- http://code.google.com/p/msysgit/[Git per MSys] è un alternativa che +- https://gitforwindows.org/[Git per Windows] è un alternativa che richiede meno risorse, anche se alcuni comandi necessitano ancora di essere migliorati. diff --git a/it/preface.txt b/it/preface.txt index f7563655..1f44d526 100644 --- a/it/preface.txt +++ b/it/preface.txt @@ -26,7 +26,7 @@ combinati per sopperire alle nostre necessità. e JiangWei. Conversione in link:/~blynn/gitmagic/intl/zh_tw/[Cinese tradizionale] tramite +cconv -f UTF7-CN -t UTF8-TW+. - link:/~blynn/gitmagic/intl/fr/[Francese]: Alexandre Garel, Paul - Gaborit, e Nicolas Deram. Anche scaricabile da http://tutoriels.itaapy.com/[itaapy]. + Gaborit, e Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[Tedesco]: Benjamin Bellee e Armin Stebich; anche scaricabile dal http://gitmagic.lordofbikes.de/[sito web di Armin]. diff --git a/ko/basic.txt b/ko/basic.txt index f2ef7233..47025f65 100644 --- a/ko/basic.txt +++ b/ko/basic.txt @@ -1,50 +1,50 @@ ==기본적인 요령== -Git 명령어의 바다 속에 곧바로 빠지는 것 보단, 다음 기본적인 예제를 통해서 -천천히 배우는 방법이 좋을 것입니다. 표면적으로는 간단하게 보이지만, 이 곳 예제들은 앞으로 많은 도움이 될 것입니다. -저 역시도 처음 Git을 사용할 때에는 아래에 있는 예제 외에 다른 것들은 건들여 보지도 않았습니다. +Git의 수많은 명령어 속으로 곧바로 다이빙 하는 것 보단, 다음 간단한 예시들을 통해서 +천천히 배우는 방법이 좋을 것 같습니다. 제가 소개하는 예시들은, 표면적으로는 간단하게 보이지만, 앞으로 여러방면으로 많은 도움이 될 것입니다. +저 역시도 처음 Git을 사용할 때에는 아래에 있는 예시 외에는 건들여 보지도 않았습니다. === 상태 (state) 저장하는 방법=== -무엇인가 대단한 것을 해보고 싶으시다고요? 그러시기 전에, 현 디렉토리에 들어있는 +파일에 무엇인가 큰 변화를 주고 싶으시다고요? 그러시기 전에, 현 디렉토리에 들어있는 모든 파일의 스냅샷을 찍어봅시다: $ git init $ git add . $ git commit -m "My first backup" -만약에 편집을 하다가 잘 못됬다면, 예전의 편집되기 전의 깨끗한 버전을 되돌리면 됩니다: +위 명령어들을 입력 후, 만약에 편집을 하다가 잘못됬다면, 편집되기 전의 깨끗한 버전으로 되돌리면 됩니다: $ git reset --hard -다시 state를 저장하고 싶다면: +또 어떤 작업 후 state를 저장하고 싶다면: $ git commit -a -m "Another backup" === 파일 더하기 (add), 지우기 (delete), 이름 바꾸기 (rename) === -위의 간단한 요령들은 처음 *git add* 명령어를 실행했을 때 이미 존재하던 파일들만 저장하게 됩니다. 새로운 파일들이나 하위 디렉토리들을 추가했다면: +위의 간단한 요령들은 처음 *git add* 명령어를 실행했을 때 이미 존재하던 파일들만 저장하게 됩니다. 존재하던 파일의 편집 이외의 새로운 파일들이나 하위 디렉토리들을 추가했다면, Git에게 알려줘야 합니다: $ git add readme.txt Documentation -그리고 만약에 원하지 않는 파일을 Git에서 없애려면: +그리고 만약에 원하지 않는 파일을 Git에서 없애려면 그것 역시 Git에게 알려줘야 합니다: $ git rm kludge.h obsolete.c $ git rm -r incriminating/evidence/ 이렇게 함으로써 Git은 지정한 파일들을 지워주게 됩니다. -파일 이름바꾸기는 원치않는 현재의 이름을 지우고 새로운 이름을 새롭게 지정하는 컨셉과 같습니다. 좀 더 손쉬운 방법으로는 *git mv* 명령어가 있습니다. 예를 들어: +Git 파일이름을 바꿀때에는 원치않는 일반파일들의 이름을 지우고 새로운 이름을 새롭게 지정하는 간단한 절차와 같습니다. 좀 더 손쉬운 방법으로는 *git mv* 명령어가 있습니다. 예를 들어: $ git mv bug.c feature.c === 고급 undo와 redo === -가끔씩은 작업을 하다가 하던 일을 멈추고 전 버전으로 돌아가고 싶다거나, 한 시점 이후의 모든 편집을 지우고 싶을 때가 있을 것입니다. 그렇다면: +가끔씩은 작업을 하다가 하던 일을 멈추고 전 버전으로 돌아가고 싶다거나, 어느 시점 이후의 모든 편집을 지우고 싶을 때가 있을 것입니다. 그렇다면: $ git log -이 명령어는 최근에 commit들을 정리한 리스트와 그의 SHA1을 보여줍니다. +이 명령어는 최근의 commit들을 정리한 리스트와 그의 SHA1 hashes를 보여줍니다: ---------------------------------- commit 766f9881690d240ba334153047649b8b8f11c664 @@ -61,7 +61,7 @@ Date: Thu Jan 1 00:00:00 1970 +0000 ---------------------------------- Hash 앞의 알파벳 몇 개만으로도 commit을 세분화 설정하실 수 있습니다; -다른 방법으로는, hash 전문을 복사/붙여넣기 하는 방법도 있지요: +다른 방법으로는, 아래의 명령어와 같이 hash 전문을 복사/붙여넣기 하는 방법도 있지요: $ git reset --hard 766f @@ -71,34 +71,34 @@ Hash 앞의 알파벳 몇 개만으로도 commit을 세분화 설정하실 수 $ git checkout 82f5 -이 명령어는 새로운 commit들을 보존함과 동시에 과거의 시간으로 잠시 돌아가게 해줍니다. 그러나, SF영화에서 처럼, 과거에 돌아간 상태에서 편집을하고 commit을 한다면 다른 시간대의 현실을 만들어가게 되는 것이죠. 왜냐하면 당신의 편집이 과거의 편집과는 다르게 입력이 되었기 때문입니다. +이 명령어는 82f5 이후의 commit들을 보존함과 동시에 과거의 시간으로 잠시 돌아가게 해줍니다. 그러나, SF영화에서 처럼, 과거에 돌아간 상태에서 편집을하고 commit을 한다면 또 다른 시간대의 현실을 만들어가게 되는 것이죠. 왜냐하면 당신의 편집이 과거의 편집과는 다르게 입력이 되었기 때문입니다. -이런 대체현실을 'branch (나뭇가지)'라고 부릅니다 <>에 관해선 추후에 자세히 설명합니다>>. 지금 알고계셔야 할 것은 +이렇게 새롭게 만들어진 대체현실을 'branch (나뭇가지)'라고 부릅니다 <>. 지금 알고계셔야 할 것은 $ git checkout master -이 것은 현재시간의 state로 오게 해줄 것입니다. 그리고 Git이 푸념을 놓기전에 편집했던 사항들이 있다면 -master branch로 돌아오기전 commit을 하거나 reset을 하시길 바랍니다. +이 명령어는 과거에서 현재의 state로 돌아오게 해줄 것입니다. 그리고 Git이 유저에게 푸념을 놓기전에 과거에서 편집했던 사항들이 있다면 +master branch로 돌아오기전 commit을 하거나 reset을 한번 실행하시길 바랍니다. -컴퓨터 게임과 또 다시 비교해본다 하면: +게임과 또 다시 비교해본다 하면: - *`git reset --hard`*: 예전에 세이브 해뒀던 게임으로 돌아가며, 돌아간 시점 이후의 세이브들을 모두 삭제합니다. -- *`git checkout`*: 예전에 세이브 해뒀던 게임으로 돌아가며, 돌아간 시점 이후의 게임들은 처음 세이브와 다른 길을 가게 됩니다. 추후의 모든 세이브들은 다른 branch로써 새로운 현실세계를 만들게 됩니다 <>에 관해선 추후에 자세히 설명합니다>>. +- *`git checkout`*: 예전에 세이브 해뒀던 게임으로 돌아가며, 돌아간 시점 이후의 게임들은 처음 세이브와 다른 길을 가게 됩니다. 추후의 모든 세이브들은 다른 branch로써 새로운 현실세계를 만들게 됩니다 <>. 예전의 파일/하위 디렉토리들을 되돌리고 싶을 때 다음 명령어를 이용함으로써 필요한 파일/하위 디렉토리만을 되돌릴 수 있습니다: $ git checkout 82f5 some.file another.file -그러나 이 *checkout* 핸들이 다른 파일들을 조용히 덮어씌우기 할 수 있다는 점을 알아두세요. 이러한 사고를 방지하고 싶다면 -checkou 명령어를 쓰기전에 commit을 이용하세요. Git을 처음 이용하는 분들은 특히 더 조심하시기 바랍니다. +그러나 이 *checkout* 명령어가 다른 파일들을 조용히 덮어씌우기 할 수 있다는 점을 알아두세요! 이러한 사고를 방지하고 싶다면 +checkout 명령어를 쓰기전에 commit을 이용하세요. Git을 처음 이용하는 분들은 특히 더 조심하시기 바랍니다. 대체적으로 파일이 삭제될까 두려우시다면 *git commit -a*를 우선해놓고 생각하세요. -Hash를 자르고 붙여넣기 싫으시다고요? 그렇다면: +긴 hash 전체를 복붙하기 싫으시다고요? 그렇다면: $ git checkout :/"My first b" -이 명령어를 사용함으로써 이 message로 commit을 해두었던 state로 돌아갈 수 있습니다. +이 명령어를 사용함으로써 이 commit message를 사용해서 commit했었던 state로 돌아갈 수 있습니다. 그리고 이 다음 명령어로 5번 스텝 전의 state로 돌아갈 수도 있습니다: $ git checkout master~5 @@ -134,15 +134,15 @@ Git으로 관리되는 프로젝트 사본을 얻기위해서는: === 최첨단 기술 === -*git clone* 명령어를 이용해 어떤 프로젝트의 사본을 다운로드했다면, 다음 명령어를 이용해 그 프로젝트의 최신버전으로 업그레이드 할 수 있습니다: +*git clone* 명령어를 이용해 어떤 프로젝트의 사본을 다운로드 해뒀다면, 다음 명령어를 이용해 그 프로젝트의 최신버전으로 업데이트 할 수 있습니다: $ git pull === 즉석 발행 === -당신이 다른 사람들과 공유하고 싶은 스크립트를 작성했다고 가정합니다. 당신은 그들에게 당신의 컴퓨터에서 다운로드를 받으라고 할 수있지만, 당신 친구들이 만약 당신이 편집하는 도중에 받게된다면, 그들은 예상치 못 한 트러블에 걸릴 수 있습니다. 이러한 이유 때문에 릴리스 사이클이란 것이 존재하는 것입니다. 개발자들은 개발 중인 프로젝트에 자주 들락날락 거릴 것이고, 그들은 남 앞에 내놓을 만한 프로젝트로 만들어지기 전까지 남들에게 보여주게 되지 않을겁니다. +당신이 다른 사람들과 공유하고 싶은 스크립트를 작성했다고 가정합니다. 당신은 그들에게 당신의 컴퓨터에서 다운로드를 받으라고 할 수있지만, 당신 친구들이 만약 당신이 해당 스크립트를 편집하는 도중에 받게된다면, 그들은 예상치 못한 트러블에 걸릴 수 있습니다. 이러한 이유 때문에 릴리스 사이클이란 것이 존재하는 것입니다. 개발자들은 개발 중인 프로젝트 디렉토리에 자주 들락날락 거릴 것이고, 그들은 그들이 한 작업이 다른 사람들 앞에 내놓을 만한 상태로 만들어지기 전까지 남들에게 보여주지 않을겁니다. -Git으로 이런 문제를 해결할려면, 당신의 스크립트가 들어있는 디렉토리에서: +Git으로 릴리스 사이클을 맞추려면, 당신의 스크립트가 들어있는 디렉토리에서: $ git init $ git add . @@ -152,7 +152,7 @@ Git으로 이런 문제를 해결할려면, 당신의 스크립트가 들어있 $ git clone your.computer:/path/to/script -그들이 이렇게하면 당신의 스크립트를 다운로드 할 수 있을 것입니다. 이 작업은 ssh 접근을 가정합니다. 그렇지 않다면, 당신은 *git daemon* 명령어를 쓴 후 친구들에게 다음 명령어를 써보라고 합니다: +그들이 이렇게하면 당신의 스크립트를 다운로드 할 수 있을 것입니다. 이 작업은 다른 유저들이 ssh 접근을 할수있다고 가정합니다. 그렇지 않다면, 소유주인 당신이 *git daemon* 명령어를 쓴 후 친구들에게 다음 명령어를 쓰라고 하십시오: $ git clone git://your.computer/path/to/script @@ -172,28 +172,28 @@ Git으로 이런 문제를 해결할려면, 당신의 스크립트가 들어있 $ git diff -아니면 어제부터 어떤 변화가 있었는지 확인하기 위해서는: +어제부터 어떤 변화가 있었는지 확인하기 위해서는: $ git diff "@{yesterday}" -아니면 어떤 특정 버전에서 부터 2번째 전 버전 사이의 변화를 확인하기 위해서는: +어떤 특정 버전에서 부터 2번째 전 버전 사이의 변화를 확인하기 위해서는: $ git diff 1b6d "master~2" 각각의 결과는 *git apply*와 함께 적용할 수 있는 패치가 될 것입니다. - 다음 명령어도 사용해 보세요: +다음 명령어도 사용해 보세요: $ git whatchanged --since="2 weeks ago" -저는 가끔씩 http://sourceforge.net/projects/qgit[qgit] 에 들어가서 히스토리를 체크하곤 합니다. 이 웹사이트는 깨끗한 그래픽 인터페이스로 구성되어 있어 보기 쉽지요. 아니면, http://jonas.nitro.dk/tig/[tig], 텍스트형식 인터페이스 역시 느린 연결방식을 가지고 있는 분들에겐 도움이 될 것입니다. 또 다른 방법으로는 웹 서버를 설치한 후 *git instaweb*명령어를 사용하는 방법도 있겠지요. +저는 윗 방법대신 http://sourceforge.net/projects/qgit[qgit] 를 따로 다운받아서 commit 히스토리를 체크하곤 합니다. 이 프로그램은 깨끗한 그래픽 인터페이스로 구성되어 있어보기 쉽지요. 아니면, http://jonas.nitro.dk/tig/[tig], 텍스트형식 인터페이스 역시 느린 인터넷속도를 가지고 있는 분들에겐 도움이 될 것입니다. 또 다른 방법으로는 웹 서버를 설치한 후 *git instaweb*명령어를 사용하는 방법도 있겠지요. === 연습 === -우선 A, B, C, D 를 각각 연속된 commit이라고 가정합니다. 그리고 B는 A 에서 몇 개의 파일들이 삭제된 버전으로 가정합니다. 문제는 여기서 몇몇 파일들을 D에 더하고 싶을 때 어떻게 하는건가 입니다. +우선 A, B, C, D 를 각각 연속된 한 파일에 대한 commit이라고 가정합니다. 그리고 B는 A 에서 몇 개의 파일들이 삭제된 버전으로 가정합니다. 문제는 여기서 그 삭제된 파일들을 D에 더하고 싶을 때 어떻게 하는 것 인가 입니다. -세가지의 해답을 찾을 수 있겠군요. 우선 우리가 현재 D에 있다고 생각합시다: +적어도 세가지의 방법이 있습니다. 우선 우리가 현재 D에 있다고 생각합시다: - 1. A와 B의 차이점은 몇 개의 파일들이 없어진 것 뿐입니다. 우리는 이 차이점을 패치로 작성하여 적용할 수 있습니다.: + 1. A와 B의 차이점은 몇 개의 지워진 파일들 뿐입니다. 우리는 이 차이점을 패치로 따로 작성하여 본래의 디렉토리에 적용할 수 있습니다: $ git diff B A | git apply @@ -205,4 +205,4 @@ Git으로 이런 문제를 해결할려면, 당신의 스크립트가 들어있 $ git revert B -어떤 방법이 가장 좋은 해답일까요? 답은 본인이 원하는 것이 곧 해답입니다. Git을 이용한다면 당신이 원하는 것은 쉽게 해낼 수 있고, 그 것을 해내는 방법은 한가지만 있는 것이 아닐 겁니다. +어떤 방법이 가장 좋은 해답일까요? 답은 본인이 원하는 것이 곧 해답입니다. Git을 이용한다면 당신이 원하는 것은 쉽게 해낼 수 있고, 그 것을 해내는 방법은 한가지만 있는 것이 아닐겁니다. diff --git a/ko/branch.txt b/ko/branch.txt index 5ab73e75..0eb5a0e7 100644 --- a/ko/branch.txt +++ b/ko/branch.txt @@ -1,37 +1,35 @@ -== 나뭇가지 (branch) 마법 == +== 브랜칭 마법 == -Git의 죽이는 기능들 중에는 즉석으로 브랜칭 및 병합이 가능하다는 것입니다. +Git의 끝내주는 기능들 중에는 즉석으로 브랜칭 (brancing) 및 병합 (merging)이 가능하다는 것입니다. -*예시문제*: 외부적인 요소들은 불가피하게 당신이 하던 일은 그만두게 합니다. 예를 들어, 치명적인 버그가 -이미 배포된 버전에서 경고없이 퍼저나가게 생겼습니다. 프로그램에 새로 넣어야 할 -기능이 있는데 데드라인은 가까워져 옵니다. 당신이 도움을 요청하고자 했던 개발자는 퇴사할려고 하니 도움을 요청할 수도 없고요. 시간이 촉박한 만큼 하던 일을 멈추고 버그를 고치는 데에 올인을 해야겠지요. +*예시*: 외부적인 요소들은 가끔 불가피하게 당신이 하던 일을 그만두게 합니다. 예를 들어, 치명적인 버그가 경고없이 퍼져나가게 생겼습니다. 프로그램에 새로 넣어야 할 기능이 있는데 데드라인은 가까워져 옵니다. 당신이 도움을 요청하고자 했던 개발자는 퇴사할려고 하니 도움을 요청할 수도 없고요. 시간이 촉박한 만큼 하던 일을 멈추고 버그를 고치는 데에 올인을 해야겠지요. -위와 같이 하던 일을 멈추는 것은 일의 생산성을 치명적으로 떨어트립니다. 특히나 지금까지 하던 일과 정 상관없는 부분의 프로그램을 건들어야 할 때 말이죠. 이럴 때, 중앙 버전 관리 시스템을 사용하는 경우엔 작동이 되는 버그없는 프로그램을 다시 받아야 합니다. 분산 관리 시스템일 경우에는 원하는 버전만 로컬 컴퓨터로 받아내면 되죠. +위의 예시와 같이 하던 일을 갑자기 멈추는 것은 일의 생산성을 치명적으로 떨어트립니다. 특히나 지금까지 하던 일과 정 상관없는 부분의 프로그램을 건들어야 할 때 말이죠. 이럴 때, 중앙관리식 VCS를 사용하는 경우엔 버그없는 버전의 프로그램을 새로 다시받아야 할껍니다. 분산관리식 VCS일 경우에는 원하는 버전만 로컬 컴퓨터로 받아내면 되죠. -하지만 클로닝은 작업 중인 디렉토리 포함 그 디렉토리의 히스토리를 어느 선까지는 같이 다운로드 받게 합니다. Git은 최대한 효율성있게 시스템이 디자인되어 있지만, 클로닝 명령어를 쓴다면 프로젝트 파일들이 (비효율적으로) 현재 작업 중인 디렉토리에 전부 다시 생성될 것입니다. +하지만 클로닝은 작업 중인 디렉토리 포함 그 디렉토리의 히스토리를 어느 선까지는 같이 다운로드 받게 합니다. Git은 최대한 효율성있게 시스템이 디자인되어 있긴하지만, 클로닝 명령어를 쓴다면 프로젝트 파일들이 (비효율적으로) 현재 작업 중인 디렉토리에 전부 다시 생성될 것입니다. *해답*: Git은 이런 상황에서 좀 더 빠르고 공간적으로 효율성있게 클로닝을 할 수 있는 명령어를 가지고 있습니다: *git branch* -이런 환상적인 명령어를 이용하여 디렉토리에 있는 파일들은 탈바꿈을 감행해 이 버전과 저 버전을 넘나들 수 있습니다. 이 변형기법은 버전 사이를 넘나드는 것 외에도 더 많은 것을 할 수 있습니다. 당신의 파일들은 전 버전에서 실험할 있는 임시버전, 개발버전, 친구들이 보유하고 있는 버전 등으로 변형할 수 있습니다. +이런 환상적인 명령어를 이용하여 디렉토리에 있는 파일들은 탈바꿈을 감행해 이 버전과 저 버전을 넘나들 수 있습니다. 이 변형기법은 버전 사이를 넘나드는 것 외에도 더 많은 것을 할 수 있습니다. 당신의 프로젝트는 브랜칭을 통해 구버전에서 임시버전, 개발버전, 친구들이 보유하고 있는 버전 등으로 아무렇게나 변형할 수 있습니다. === 일하는 척 하기 버튼 === 버튼 하나만 누르면 ("일하는 척 하기 버튼") 게임화면이 최소화되고 엑셀파일이 화면상에 나타나는 기능을 보신 적이 있을겁니다. 이 기능을 활용하면 직장상사의 눈을 속이고 일하던 척 할 수 있지요? -아무 디렉토리에서: +어떤 디렉토리에서: $ echo "I'm smarter than my boss" > myfile.txt # 난 내 상사보다 똑똑하다 $ git init $ git add . $ git commit -m "Initial commit" -우리는 "난 내 상사보다 똑똑하다"라는 내용을 가진 텍스트파일을 Git 저장소에 만들었습니다. 그리고: +우리는 "난 내 상사보다 똑똑하다"라는 내용을 가진 텍스트파일을 Git repository에 만들었습니다. 그리고: $ git checkout -b boss # 이 명령어를 사용한 후엔 아무것도 바뀌지 않은 것처럼 보일겁니다. - $ echo "My boss is smarter than me" > myfile.txt # 상사는 나보다 똑똑합니다 + $ echo "My boss is smarter than me" > myfile.txt $ git commit -a -m "Another commit" -겉으로 보기에는 그 텍스트파일을 새로운 (맘에 들지않는) 문장으로 덮어씌우고 commit을 한 것처럼 보일겁니다. 그러나 그건 착각입니다. 다음 명령어를 입력해보세요: +겉으로 보기에는 그 텍스트파일을 새로운 문장으로 덮어씌우고 commit을 한 것처럼 보일겁니다. 그러나 그건 착각입니다. 다음 명령어를 입력해보세요: $ git checkout master # 처음 버전으로 돌아가기 @@ -49,7 +47,7 @@ Git의 죽이는 기능들 중에는 즉석으로 브랜칭 및 병합이 가능 $ git commit -a $ git checkout HEAD~3 -이제 테스팅하고 싶었던 파일에 더하고 싶은 것을 걱정없이 마구 넣어도 됩니다. 이 미친 짓(?)을 Commit 해놓을 수도 있습니다. 작업이 다 끝났다면, +이제 테스팅하고 싶었던 파일에 더하고 싶은 것을 걱정없이 마구 넣어도 됩니다. 이 미친 짓(?)을 commit 해놓을 수도 있습니다. 작업이 다 끝났다면, $ git checkout master @@ -65,9 +63,9 @@ Git의 죽이는 기능들 중에는 즉석으로 브랜칭 및 병합이 가능 우리는 이 체크아웃이라는 명령어를 전에도 설명했었죠. 여기서는 이 명령어가 어떻게 예전 버전들을 불러오는 지 살펴볼 수 있었습니다: 파일을 원하는 버전으로 돌아가게 할 수 있으나, master 나뭇가지를 우선 벗어나야 하지요. 벗어난 후의 commit은 master 나뭇가지와는 다른 길을 걷게 될 것입니다. 그 길을 나중에 이름도 지어줄 수 있지요. -다시 말하면, 예전 상태 (state)에서 벗어나면 Git은 자동으로 이름이 (아직) 붙여지지 않은 새로운 나뭇가지로 이동시켜 줍니다. 이 나뭇가지는 *git checkout -b*로 이름을 바꿔 저장해줄 수 있죠. +다시 말하면, 예전 상태 (state)에서 벗어나면 Git은 자동으로 이름이 없는 새로운 나뭇가지로 이동시켜 줍니다. 이 나뭇가지는 *git checkout -b*로 이름을 바꿔 저장해줄 수 있죠. -=== 빠른 해결책 === +=== 빠른 코드수정 === 작업 중에 갑자기 하던 일을 멈추고 '1b6d...'commit에 있는 버그를 고치라고 부탁을 받았다고 생각해 봅시다: @@ -85,24 +83,24 @@ Git의 죽이는 기능들 중에는 즉석으로 브랜칭 및 병합이 가능 === 병합 (Merging) === -Git을 제외한 어떤 버전 컨트롤 시스템들을 이용할 땐 나뭇가지 (branch)들을 만드는 것은 쉽지만 -나뭇가지들을 병합하기는 어려울지도 모릅니다. Git에서는 병합작업이 정말 쉽고 -병합이 진행되고 있는 중인지도 모르는 사이에 끝날 것입니다. +Git을 제외한 다른 VCS들을 이용할 땐 나뭇가지 (branch)들을 만드는 것은 쉽지만 +나뭇가지들을 병합하기는 어려웠습니다. Git에서는 병합작업이 정말 쉽고 +병합이 진행되고 있는 중인지 우리도 모르는 사이에 끝날 것입니다. -우리는 병합을 아까 전에도 소개했었습니다. 당겨오기 (*pull*) 명령어는 -commit들을 가져와 지금 사용중인 나뭇가지에 병합하여 줍니다. 로컬에서 아무런 -편집작업을 진행하지 않았더라면 *pull*은 현 나뭇가지를 '빨리 감기' 하여 -중앙 서버에서 가장 최근의 정보를 가져와 병합합니다. 로컬에서 편집작업을 한 -기록이 있다면, Git은 자동으로 병합을 시도할 것이고, 병합에 버전간의 차질이 있다면 당신에게 보고할 것 입니다. +병합은 전에도 소개했었습니다. '당겨오기 (pull)' 명령어는 +commit들을 가져와 지금 머물고있는 branch에 병합하여 줍니다. 로컬에서 아무런 +작업을 진행하지 않았더라면 *pull*은 현 branch를 '빨리 감기' 하여 +중앙 서버에서 가장 최근의 정보를 가져와 병합합니다. 로컬에서 작업을 한 +기록이 있었다면, Git은 자동으로 병합을 시도할 것이고, 병합 중에 버전간의 차질이 있다면 당신에게 친절히 알려줄 것 입니다. -Commit은 보통 하나의 '부모 commit'이 있습니다. 병합을 다르게 생각해보면 -한 commit이 적어도 두 개의 '부모 commit'이 있다고 생각할 수 있는 것이죠. -그럼 'HEAD~10'은 어떤 commit을 가르키는 걸까요? 부모가 하나가 아니라면 -어떤 것을 거슬러 올라가야 전 버전에서 작업할 수 있을까요? +Commit은 보통 하나의 '부모 commit'이 (과거의 commit) 있습니다. 그러나 병합을 하게 된다면 +하나의 commit이 적어도 '아버지 commit'와 '어머니 commit' 이 있다고 생각할 수 있는 것이죠. +그럼 'HEAD~10'은 어떤 commit을 가르키는 걸까요? 부모 commit 두 개 이상이라면 +어떤 commit을 받아 순조롭게 작업을 계속 진행할 수 있을까요? -Git은 먼저 commit되었던 부모를 따르게 설정되어 있습니다. 현재 작업중인 -나뭇가지가 병합이 실행될 경우 첫번째 부모가 되기때문에 당연한 겁니다.: -당신은 언제나 현 나뭇가지에 가장 최근에 한 작업에만 관심이 있을 수 밖에 없기 때문이지요. +Git은 먼저 시간적으로 제일 먼저 commit되었던 부모를 따르게 설정되어 있습니다. 현재 작업중인 +branch가 병합이 실행될 경우 이 branch 자체가 첫번째 부모가 되기때문에 당연한 겁니다: +당신은 언제나 현 나뭇가지에서 가장 최근에 한 작업에만 관심이 있을 가능성이 크기 때문이지요. 다른 나뭇가지에서 한 작업은 다음 일입니다. 탈자 기호 (^)를 이용하서 부모를 수동으로 정해줄 수도 있습니다. 예를 들어 @@ -131,10 +129,10 @@ Git은 먼저 commit되었던 부모를 따르게 설정되어 있습니다. 현 당신의 코드가 받아 들여지기 전 검토부터 되어야 겠지요. 그래서 당신은 그 검토가 끌날 때까지는 다음 작업으로 진행하지 못 할것입니다. -하지만 나뭇가지와 병합기능 덕분에 이 규치을 깨고 파트 1이 완료되기도 전에 +하지만 나뭇가지와 병합기능 덕분에 이 규칙을 깨고 파트 1이 완료되기도 전에 파트 2에서 미리 작업을 진행하고 있을 수 있습니다. 파트 1을 commit하고 -검토를 위해 어디론가 보냈다고 생각하십시오. Master 나뭇가지에서 있었다면, -그 나뭇가지에서 다른 나뭇가지로 갈아타야합니다: +검토를 위해 어디론가 보냈다고 생각해봅시다. 만약 당신이 Master 나뭇가지에서 작업하고 있었다면, +그 branch에서 다른 branch로 갈아타야합니다: $ git checkout -b part2 @@ -155,9 +153,9 @@ Git은 먼저 commit되었던 부모를 따르게 설정되어 있습니다. 현 $ git merge part2 # 파트 2도 파트 1으로 병합. $ git branch -d part2 # 파트 2 나뭇가지 삭제. -이제 파트 2의 모든 것과 함께 master 나뭇가지로 돌아왔습니다. +이제 파트 2의 모든 것과 함께 업데이트 된 master 나뭇가지로 돌아왔습니다. - 나뭇가지는 제한 없이 원하는 만큼 생성할 수 있습니다. 거꾸로도 나뭇가지를 만들 수도 + branch는 갯수의 제한 없이 원하는 만큼 생성할 수 있습니다. 역순으로 branch를 만들 수도 있죠: 만약에 7번의 commit전에 나뭇가지를 하나 만들어 놓았어야 함을 늦게 깨닫았을 때, 다음 명령어를 이용해 보세요: @@ -166,14 +164,14 @@ Git은 먼저 commit되었던 부모를 따르게 설정되어 있습니다. 현 Master 나뭇가지는 이제 part 1만 들어있고, 나머지는 모두 part 2에 들어가게 되었습니다. 그리고 우리는 지금 part 2에서 작업을 하고 있는 중이겠지요; master를 만들면서 master로는 -현재 작업공간을 옮겨가지 않았습니다. 처음 보시죠? 여태까지 설명한 예제들에서는 +현재 옮겨간 상태가 아닙니다. 처음 보시죠? 여태까지 설명한 예제들에서는 나뭇가지를 만들면서 곧바로 작업공간도 같이 옮겨갔었는데 말이죠. 이런 식으로요: $ git checkout HEAD~7 -b master # 나뭇가지를 만들고 바로 작업공간도 그 나뭇가지로 옮긴다. === 메들리의 재정리 === -하나의 나뭇가지에서 모든 작업을 끝내고 싶을 수도 있습니다. 작업중인 일들은 혼자만 알고 중요한 commit들만 다른사람들에게 보여주고 싶을 수 있습니다. 그럴경우엔 두 개의 나뭇가지를 우선 만드세요: +하나의 branch에서 모든 작업을 끝내고 싶을 수도 있습니다. 작업중인 일들은 혼자만 알고 중요한 commit들만 다른사람들에게 보여주고 싶을 수 있습니다. 그럴경우엔 두 개의 branch를 우선 만드세요: $ git branch sanitized # 정돈된 commit을 보여주기 위한 나뭇가지를 만듭니다. $ git checkout -b medley # 작업을 하게 될 "메들리" 나뭇가지를 만들어 이동합니다. @@ -183,34 +181,32 @@ Master 나뭇가지는 이제 part 1만 들어있고, 나머지는 모두 part 2 $ git checkout sanitized $ git cherry-pick medley^^ -위의 명령어들을 차례로 사용한다면 "메들리" 나뭇가지의 commit들을 "sanitzed" 나뭇가지에 붙입니다. "cherry-pick"명령어를 잘 사용한다면 영구적인 코드들만 들어있는 나뭇가지를 만들 수 있습니다. 그리고 그 commit들은 서로 연계가 잘 되어있을 것입니다. +위의 명령어들을 차례로 사용한다면 "메들리" 나뭇가지의 commit들을 "sanitzed" 나뭇가지에 붙입니다. "cherry-pick"명령어를 잘 사용한다면 마지막 결과물에만 첨부된 코드들이 들어있는 branch를 만들 수 있습니다. 잡다한 commit들도 잘 정리되어 있을겁니다. -=== 나뭇가지 관리하기 === +=== Branch 관리하기 === 여태까지 프로젝트에서 생성한 나뭇가지들을 보려면: $ git branch -기본적으로 "master" 나뭇가지에서 작업을 시작하는 것이 디폴트로 지정되어 있습니다. 그러나 어떤 개발자들은 -"master" 나뭇가지는 그대로 냅두고 새로운 나뭇가지를 만들어서 그 곳에서 작업하는 것을 선호합니다. +기본적으로 "master" 나뭇가지에서 작업을 시작하는 것이 디폴트로 지정되어 있습니다. 그러나 어떤 개발자들은 "master" 나뭇가지는 그대로 냅두고 새로운 나뭇가지를 만들어서 그 곳에서 작업하는 것을 선호합니다. -*-d*와 *-m* 옵션들은 각각 나뭇가지들을 지우거나 이름을 바꿔줄 수 있는 파라메터들 입니다. +*-d*와 *-m* 옵션들은 각각 branch들을 지우거나 branch 이름을 바꿔줄 수 있는 파라메터들 입니다. *git help branch*를 보시면 더욱 자세히 설명되어 있을겁니다 (번역 주: 어차피 영어입니다) -"master" 나뭇가지는 유용한 관례적인 이름의 나뭇가지일 뿐입니다. 다른 개발자들은 -당신의 저장소에 당연히 "master"라는 이름을 가진 나뭇가지가 있을 것이라고 생각하겠지요. 그리고 -그 나뭇가지는 모든 공식적인 자료들일 들어있다고 넘겨짚을 것입니다. 그러나 당신은 "master"를 없에거나 -새로운 이름을 지정해줄 수 있으나, "master" 나뭇가지를 쓰는 관례를 따르는 것을 추천합니다. +"master" 나뭇가지는 관례적인 이름의 branch일 뿐입니다. 다른 개발자들은 +당신의 저장소에 당연히 "master"라는 이름을 가진 branch가 있을 것이라고 생각하겠지요. 그리고 +그 branch는 모든 공식적인 자료들이 들어있다고 넘겨짚을 것입니다. 물론 당신은 "master"를 없에거나 새로운 이름을 지정해줄 수 있으나, "master" 나뭇가지를 쓰는 관례를 따르는 것을 추천합니다. -=== 임시 나뭇가지 === +=== 임시 branch === -Git을 사용하다보면 당신은 쓸모없는 하루살이의 나뭇가지들을 많이 만들고 있다는 사실을 -깨달을 것입니다. 이유는 다음과 같겠지요: 그 많은 나뭇가지들은 작업의 경과를 -저장하기 위해 만들어 놓고 무엇인가 고칠 것이 있을 때 빨리 돌가가기 위해서 +Git을 사용하다보면 당신은 쓸모없는 하루살이 같은 쓸때없는 branch들을 많이 만들고 있다는 사실을 +깨달을 것입니다. 이유는 다음과 같겠지요: 그 많은 branch들은 작업의 경과를 +저장하기 위해 임시로 만들어놓고 무엇인가 고칠 것이 있을 때 빨리 돌가가기 위해서 쌓아두기만 하고있는 거겠죠. 다른 TV채널에서 무얼하나 확인할 때 잠시 채널을 바꾸는 것과 같은 아이디어입니다. -그러나 리모트 버튼 몇 개 누르면 되는 것과는 달리, 많은 나뭇가지를 만들고, 설정하고, 병합하고, +그러나 리모콘 버튼 몇 개 누르면 되는 것과는 달리, 많은 나뭇가지를 만들고, 설정하고, 병합하고, 나중에 다쓰면 지워야합니다. 다행히도 Git에서는 TV 리모트와 비슷하게 지름길이 있습니다: @@ -220,15 +216,15 @@ Git을 사용하다보면 당신은 쓸모없는 하루살이의 나뭇가지들 돌아갑니다. 작업중인 디렉토리는 작업 (편집, 버그고침 등) 하기 전의 상태로 돌아가겠지요. 그리고 임시 (stash)로 돌아가고 싶다면: - $ git stash apply # 에러 (version conflict)가 날지도 몰라요. + $ git stash apply # 에러 (version conflict)가 날지도 몰라요. 수동적으로 해결하세요. 물론 여러개의 임시저장소 (stash)를 만들수도 있습니다. *git help stash*에 설명이 되어있으니 -읽어보세요. 눈치챘을지 모르겠지만, Git은 올바른 임시저장소 (stash) 기능을 쓰게 해주기 위해서 나뭇가지들을 몰래 이용한답니다. +읽어보세요. 눈치챘을지 모르겠지만, Git은 올바른 임시저장소 (stash) 기능을 쓰게 해주기 위해서 자체적으로 임의 생성된 branch들을 몰래 이용한답니다. -=== 원하는 방식대로 작업하기 === +=== 내 방식대로 작업하기 === -나뭇가지를 이용하는 것이 꼭 필요한지 생각할지도 모르겠습니다. 파일들을 -클로닝하는게 제일 빠르고 *cd*를 이용해 디렉토리를 바꿈으로써 나뭇가지를 +Branch를 이용하는 것이 꼭 필요한지 생각할지도 모르겠습니다. 파일들을 +클로닝하는게 제일 빠르고 *cd*를 이용해 디렉토리를 바꿈으로써 branch 사용을 대체하고 싶을지도 모릅니다. 웹브라우저의 예를 들어보겠습니다. 여러개의 창 아니면 여러개의 탭을 지원하는 이유는 무엇일까요? @@ -237,7 +233,7 @@ Git을 사용하다보면 당신은 쓸모없는 하루살이의 나뭇가지들 반대의 형식으로 작업하는 것을 추구할지도 모르죠: 여러개의 창을 만들고 탭이 없이 작업하는 것을 말이죠. 또 어떤 이용자들은 이 두 방법들을 섞어서 작업하는 걸 선호할지도 모릅니다. -나뭇가지들은 마치 작업중인 디렉토리의 탭과 같습니다. 클로닝은 새로운 브라우저 창을 +Branch들은 마치 작업중인 디렉토리의 탭과 같습니다. 클로닝은 새로운 브라우저 창을 여는 것과 같은 것이죠. 이 두가지 방법은 모두 빠르고 로컬에서 진행됩니다. 그러니 당신에게 맞는 방법을 찾아보는 건 어떨까요? Git은 당신이 원하는 대로 일하게 도와줄 것입니다. diff --git a/ko/clone.txt b/ko/clone.txt index 4f1d14e0..a259d039 100644 --- a/ko/clone.txt +++ b/ko/clone.txt @@ -1,23 +1,23 @@ == 클론 만들기 == -구식의 버전 관리 시스템에서는 체크아웃 명령어가 파일들을 가져오는 보편적인 방법이었습니다. 저장된 포인트로 부터 많은 파일들을 불러올 수 있죠. +구형 VCS에서는 체크아웃 명령어가 어딘가에 저장되어 있는 파일들을 가져오는 보편적인 방법이었습니다. -Git을 포함한 다른 분산 제어 시스템에서는 클론만들기를 보편적인 방법으로 채택하고 있습니다. 파일을 얻기위해서는, 원하는 파일들이 저장되어있는 저장소에서 '클론'을 만들어야 합니다. 즉, 중앙 관리 서버를 미러링해오는 것과 같은 이치라고 설명할 수 있습니다. 주 저장소가 할 수 있는 모든 것들을 당신이 이제 할 수 있는 것이죠. +Git을 포함한 다른 분산 제어식 VCS에서는 클론만들기를 체크아웃을 대체하는 보편적인 방법으로 채택하고 있습니다. 어떤 저장된 파일을 얻기위해서는, 원하는 파일 원본들이 저장되어있는 저장소에서 내 컴퓨터로 끌고와 '클론'을 만들어야 합니다. 즉, 중앙관리서버를 미러링해오는 것과 같은 이치라고 설명할 수 있습니다. 클론을 본떠온다면 중앙관리서버가 할 수 있는 모든 것들을 당신이 이제 할 수 있는 것이죠. === 컴퓨터 동기화 === -기본적인 동기화 및 백업을 할 때 tarball을 만드는 것과 *rsync*명령어를 사용하는 것은 어느정도 견딜 수 있습니다. 그러나 저는 가끔씩 노트북에서 편집을 할 때도 있고, 데스크탑에서 할 때도 있는데, 이 두 개의 컴퓨터는 그리많은 대화를 나누지 않을지도 모릅니다. +기본적인 동기화 및 백업을 할 때 tarball을 만드는 것과 *rsync*명령어를 사용하는 것은 이해할 수 있는 행동입니다. 그러나 저는 가끔씩 노트북에서 편집을 할 때도 있고, 데스크탑에서 할 때도 있는데, 이 두 개의 컴퓨터는 *rsync*같은 명령어를 사용하면서 작업할때 잦은 동기화를 하지 않을지도 모릅니다. -한 컴퓨터에서 Git 저장소를 초기화하고 파일들을 commit함으로써 이 문제를 해결할 수 있습니다. 그 후 다른 컴퓨터에서: +한 컴퓨터에서 Git Repository를 초기화하고 파일들을 commit함으로써 이 문제를 해결할 수 있습니다. 그 후 다른 컴퓨터에서: $ git clone other.computer:/path/to/files -위 명령어를 이용해서 두 번째 파일/Git 저장소 사본을 만들 수 있습니다. 그 다음부터는, +위 명령어를 이용해서 두 번째 Git repository 사본을 만들 수 있습니다. 그 다음부터는, $ git commit -a $ git pull other.computer:/path/to/files HEAD -을 이용하여 현재 사용중인 컴퓨터로 다른 컴퓨터에 있는 파일들을 '당겨올 (pull)' 수 있습니다. 만약에 같은 파일에 대해서 전후가 맞지않는 편집을 했을 경우, Git은 당신에게 에러메세지로 먼저 이 모순을 해결 후 commit을 할 것을 알려줄 것입니다. +을 이용하여 현재 작업중인 컴퓨터로 다른 컴퓨터에서 작업하던 파일들을 '당겨올 (pull)' 수 있습니다. 만약에 같은 파일에 대해서 전후가 맞지않는 작업을 했을 경우, Git은 당신에게 에러메세지로 먼저 이 모순을 해결 후 commit을 할 것을 알려줄 것입니다. === 고전적인 소스 관리 === @@ -27,7 +27,7 @@ Git을 포함한 다른 분산 제어 시스템에서는 클론만들기를 보 $ git add . $ git commit -m "Initial commit" -그리고 중앙 서버에서, 아무 디렉토리에서나 간단한 저장소를 초기화 해줍니다: +그리고 중앙 서버에서, 아무 디렉토리에서나 태초의(bare) repository를 초기화 해줍니다: $ mkdir proj.git $ cd proj.git @@ -36,9 +36,9 @@ Git을 포함한 다른 분산 제어 시스템에서는 클론만들기를 보 필요하다면 Git daemon을 실행합니다: - $ git daemon --detach # it may already be running + $ git daemon --detach # 아마 이미 daemon이 실행하고 있을지도 모릅니다. -Git 호스팅 서비스를 한다면 우선 빈 Git 저장소를 만들어야 합니다. +Git 호스팅 서비스를 한다면 우선 빈 Git repository를 만들어야 합니다. 대부분 웹페이지에서 어떠한 문서를 작성하곤 하죠. 다음 명령어를 사용해 당신의 프로젝트를 중앙서버로 '밀어넣기 (push)' 할 수 있습니다: @@ -49,7 +49,7 @@ Git 호스팅 서비스를 한다면 우선 빈 Git 저장소를 만들어야 $ git clone central.server/path/to/proj.git -편집이 끝난 후에 개발자는 다음명령어를 사용해 로컬드라이브에 각종 바뀐 사항들을 저장을 합니다: +편집작업이 끝난 후에 개발자는 다음명령어를 사용해 로컬드라이브에 각종 바뀐 사항들을 저장을 합니다: $ git commit -a @@ -57,7 +57,7 @@ Git 호스팅 서비스를 한다면 우선 빈 Git 저장소를 만들어야 $ git pull -결합상의 곤란한 점들은 다음 commit 명령어를 사용하면 대부분 해결 될 것입니다: +merge할때 일어날 수 있는 오류들은 수동으로 해결 후, commit 명령어를 사용하여 작업을 commit 해주셔야 합니다: $ git commit -a @@ -65,11 +65,11 @@ Git 호스팅 서비스를 한다면 우선 빈 Git 저장소를 만들어야 $ git push -주 서버가 다른 개발자들로 인하여 새로운 변경사항이 생겼을 경우에는, '밀어넣기 (Push)'는 실패할 것입니다. -그렇다면 그 개발자는 최신 버전을 다시 당겨서 (pull) 결합후 다시 밀어넣기를 시도해야 하겠지요. +중앙 서버가 다른 개발자들로 인하여 새로운 변경사항이 생겼을 경우에는, 당신의 '밀어넣기 (Push)'는 실패할 것입니다. +그렇다면 당신은 '밀어넣기 (Push)' 하기 전에 최신 버전을 다시 당겨서 (pull) 오류를 수동으로 해결 후 다시 밀어넣기를 시도해야 하겠지요. -모든 개발자들은 push와 pull에 관한 SSH 접근권이 있어야합니다. -그러나 소스는 모든 이들에게 개방된 것으로써 다음 명령어를 이용하면 조회가 가능합니다: +모든 개발자들은 특정 Git repository에 대한 SSH 접근권한이 있어야 push와 pull를 할 수 있습니다. +그러나 개발소스는 대부분 모든 이들에게 개방된 것으로써 다음 명령어를 이용하면 조회 및 클로닝이 가능합니다: $ git clone git://central.server/path/to/proj.git @@ -78,36 +78,31 @@ Git 프로토콜은 HTTP와 비슷합니다: 증명서가 존재하지 않죠. === 숨겨진 소스 === -개방되어 있지않은 소스의 프로젝트를 진행할 때에는 터치 (Touch) 명령어를 생략합니다. 그리고 -'git-daemong-export-ok'라는 이름의 파일을 만들지 않도록 주의합니다. 이렇게하면 git 프로토콜을 사용해서 -원치않는 사람들이 당신의 저장소를 조회할 수 있는 일은 없을 것입니다; 이제는 SSH 접근권이 있는 사람들만 -조회할 수 있게 될겁니다. 당신의 모든 저장소가 개방되지 않은 경우에는 git daemon명령어는 필요없겠지요. -모든 저장소는 SSH 접근방식을 필요로 할 테니까요. +개방되어 있지않은 소스의 프로젝트를 진행할 때에는 Git의 터치 (Touch) 명령어를 생략합니다. 그리고 +'git-daemong-export-ok'라는 이름의 파일을 절대 만들지 않도록 주의합니다. 이렇게하면 git 프로토콜을 사용해서 +원치않는 사람들이 당신의 저장소를 조회하거나 클로닝 할 수 있는 일은 없을 것입니다; 이제는 SSH 접근권이 있는 사람들만 +조회할 수 있게 될겁니다. 당신의 모든 repository가 개방되지 않은 경우에는 git daemon명령어는 필요없겠지요. +모든 repository는 SSH 를 통해서만 허락된 개발자들에게만 공개될테니까요. -=== 헐벗은 저장소 === +=== 태초의 저장소 === 이 괴상한 이름의 저장소 (bare repository)는 현재 작업중인 디렉토리가 아니기에 이렇게 이름이 붙여졌습니다; 이 저장소는 하위 '.git' 디렉토리에서 숨겨진 파일들만을 저장하는 저장소입니다. 풀어 설명하면, 이 저장소는 현 프로젝트의 과거를 관리하기만 하고, 아무런 버전도 저장하지 않는 저장소입니다. -헐벗은 저장소는 버전 관리 중앙 서버와 비슷한 기능을 담당하고 있고 +헐벗은 저장소는 중앙서버관리식 VCS와 비슷한 기능을 담당하고 있고 당신의 프로젝트가 저장되어 있는 집과같은 기능을 담당하고 있습니다. 개발자들은 -이 곳에서 부터 클론을 만들 수 있고, 편집한 내용을 '밀어넣기 (Push)' 할 수 있습니다. 보편적으로 -헐벗은 저장소는 서버에서 상주하고 있다가 데이터를 퍼트리는 역할을 맡고있습니다. 개발은 -만들어진 클론에서 이루어짐으로써, 워킹 디렉토리없이 서버내에서 보호받는 저장소 역할을 할 수 있습니다. +이 곳에서 부터 클론을 만들 수 있고, 작업한 내용을 '밀어넣기 (Push)' 할 수 있습니다. 보편적으로 +이 bare repository는 서버에서 상주하고 있다가 데이터를 퍼트리는 역할을 맡고있습니다. 개발은 +개발자 각자가 만들어 놓은 로컬컴퓨터에서의 클론에서 이루어짐으로써, 워킹 디렉토리없이 서버내에서 보호받는 저장소 역할을 할 수 있습니다. -많은 Git 명령어들은 'GIT_DIR' 환경 변수가 저장소로 path가 세팅되어 있지 않는 한 이 헐벗은 저장소에 인식되지 않을 것입니다. '--bare' 옵션을 이용한다면 모를까. +많은 Git 명령어들은 'GIT_DIR' 환경 변수가 repository로 경로설정이 되어 있지않다면 이 bare repository에 인식되지 않을 것입니다. '--bare' 옵션을 이용한다면 모를까. === 밀어넣기 (push) vs. 당기기 (pull) === -당기기 (pull)에 의존하는 대신에 왜 제가 밀어넣기 (push)를 소개했을까요? -먼저, 당기기 (pull)는 아까 소개드린 헐벗은 저장소에서는 실행이 되지 않는 명령어입니다: 물론 -나중에 소개할 물어오기 (fetch)라는 명령어로 같은 일을 할 수 있지만요. 그러나 헐벗은 것 말고 보통 일반적인 저장소를 -중앙 서버에 저장해 놓는다고 해도, 당기기 (pull)는 번거로울 수 밖에 없습니다. 서버에 로그인을 해야 될 것이고 그런 후에야 -당기기 (pull)을 사용해야 하다는 말이지요. 파이어월이 이런 작업을 방해할 수도 있습니다. 그리고 쉘 접근 권한이 없다면 -중앙 서버에 접속이나 가능할런지요? +'당기기 (pull)' 커맨드에만 의존하는 대신에 왜 제가 '밀어넣기 (push)'를 소개했을까요? 먼저, 당기기 (pull)는 아까 소개드린 bare repository에서는 실행이 되지 않는 명령어입니다: 물론 나중에 소개할 '물어오기 (fetch)'라는 명령어로 같은 일을 할 수 있지만요. 그러나 중앙서버에 저장 되어있는 보통 일반적인 repository에서도, 당기기 (pull)는 번거로울 수 밖에 없습니다. 서버에 로그인을 해야 될 것이고 그런 후에야 당기기 (pull)을 사용해야 하다는 말이지요. 파이어월이 이런 절차를 방해할 수도 있습니다. 그리고 쉘 접근 권한이 없다면 중앙 서버에 접속이나 가능할런지요? -그러나 이러한 특수상황들이 아니라면 밀어넣기 (push)를 사용하실 것을 강추합니다. 목적지가 현재 작업중인 디렉토리가 있을 경우에는 굉장히 햇갈릴 수 있기 때문입니다. +그러나 이러한 특수상황들이 아니라면 밀어넣기 (push)를 사용하시는 것을 비추합니다. 목적지가 현재 작업중인 디렉토리가 있을 경우에는 굉장히 햇갈릴 수 있기 때문입니다. -줄여서, Git을 배울 때에는, 헐벗은 저장소일 경우에는 밀어넣기 (push) 아니면 당기기 (pull)을 사용합시다. +줄여서, Git을 배울 때에는, bare repository일 경우에는 '밀어넣기 (push)'를 진행하시고 아니면 '당기기 (pull)'을 사용합시다. === 프로젝트 포크질 (forking) 하기 === @@ -117,36 +112,33 @@ Git 프로토콜은 HTTP와 비슷합니다: 증명서가 존재하지 않죠. 이 명령어를 쓴 후에, 다른 사람들에게 당신이 포크질 (fork)을 한 프로젝트에 대해 알리세요. -이후 아무때나 원래 프로젝트 파일에서 다음 명령어를 씀으로써 어떠한 변화가 있었다면 포크질 해놓은 프로젝트로 병합을 실행할 수 있습니다: +이후 작업이 끝난 후 아무때나 원래 프로젝트 파일에서 다음 명령어를 씀으로써 포크질 해놓은 프로젝트로부터 오리지널 프로젝트 파일로 병합을 실행할 수 있습니다: $ git pull === 궁극의 백업 === -아무도 건들 수 없고 지리적으로 다양한 곳에 저장해놓고 싶은 기록 보관소를 소유하고 싶다고요? 만약 당신의 프로젝트에 많은 개발자들이 참여한다면 아무 것도 하지 마십시오. 클론을 만드신다면 그 클론 자체가 아주 효율적인 프로젝트 백업이 될 것 입니다. 현 상태의 프로젝트 뿐만이 아니라, 그 프로젝트의 모든 과거 버전까지 말이죠. 만약이라도 어떤 개발자 분의 클론이 훼손 된다면 암호화 된 hashing 덕에 다른 모든 개발자들이 프로젝트 훼손여부에 관해 알 수 있게 될 것입니다. +아무도 건들 수 없고 지리적으로 다양한 곳에 저장해놓고 싶은 기록 보관소를 소유하고 싶다고요? 만약 당신의 프로젝트에 많은 개발자들이 참여한다면 아무 것도 하지 마십시오. 그 수많은 개발자들이 각자 클론을 만들었다면 그 클론 자체가 아주 효율적인 프로젝트 백업이 될 것 입니다. 현 상태의 프로젝트 뿐만이 아니라, 그 프로젝트의 모든 과거 버전까지 말이죠. 만약이라도 어떤 개발자 분의 클론이 훼손 된다면 암호화 된 hashing 덕에 다른 모든 개발자들이 프로젝트 훼손여부에 관해 알 수 있게 될 것입니다. 만약 당신의 프로젝트에 그리 많은 개발자들이 참여하지 않는다면, 최대한 많은 서버를 확보해서 클론을 만들어 놓으십시오. -편집증이 걸린 개발자들은 언제나 프로젝트 HEAD의 20-바이트 SHA1 hash를 어딘가에는 안전하게 모셔놓죠. 안전하다는 말이 사적인 공간에 저장해놓는다는 말은 아닙니다. 예를 들면, 어떤 신문에 기사를 개제하는 것도 안전한 기록보관의 한 방법이지요. 그 정보를 훼손하고자하는 작자들이 세상에 발간된 모든 신문 카피를 바꿀 수는 없기 때문입니다. +편집증이 걸린 개발자들은 언제나 프로젝트 HEAD의 20-바이트 SHA1 hash를 어딘가에는 안전하게 모셔놓죠. 안전하다는 말이 꼭 사적인 공간에 저장해놓는다는 말은 아닙니다. 예를 들면, 어떤 신문에 기사를 개제하는 것도 안전한 기록보관의 한 방법이 될 수 있지요. 그 정보를 훼손하고자하는 작자들이 세상에 발간된 모든 신문 카피를 바꿀 수는 없기 때문입니다. === 광속의 멀티테스킹 === -만약에 어떠한 프로젝트의 여러군데를 동시에 작업하고 싶으실 때에는 우선 프로젝트를 한 번 commit 한 후 다음 명령어를 사용합니다: +만약에 어떠한 프로젝트의 여러 부분을 동시에 작업하고 싶으실 때에는 우선 현재상태의 프로젝트를 한 번 commit 한 후 다음 명령어를 사용합니다: $ git clone . /some/new/directory -http://en.wikipedia.org/wiki/Hard_link[hardlinking] 덕분에 클론들은 -적은 시간과 공간을 이용해 백업으로 존재해줄 수 있습니다. +http://en.wikipedia.org/wiki/Hard_link[hardlinking] 이라는 기능 덕분에 로컬시스템에 생성된 클론들은 일반 백업에 비해 비교적 적은 시간과 공간만 필요로 합니다. -이렇게 하면 두개의 독립적인 구간에서 작업을 진행할 수 있습니다. 예로, 한 클론이 컴파일 중 -다른 클론에서 작업을 진행하고 있을 수 있습니다. 그리고 다른 클론으로 부터 -아무 때나 commit과 당기기 (pull)도 사용할 수 있습니다. +이렇게 하면 두개의 독립적인 작업을 동시진행 할 수 있습니다. 예로, 한 클론이 컴파일 중일때 다른 클론에서 또 다른 작업을 진행하고 있을 수 있습니다. 그리고 다른 클론으로 부터 아무 때나 commit과 당기기 (pull)도 사용할 수 있습니다. $ git pull /the/other/clone HEAD === 게릴라 버전 관리 === -당신은 현재 다른 버전 관리 시스템을 사용하고 있지만, Git을 그리워하고 있진 않습니까? 그렇다면 현재 작업중인 디렉토리에서 Git을 초기화 시켜주십시오: +당신은 현재 다른 VCS를 사용하고 있지만, Git을 그리워하고 있진 않습니까? 그렇다면 현재 작업중인 디렉토리에서 Git을 초기화 시켜주십시오: $ git init $ git add . @@ -166,29 +158,29 @@ http://en.wikipedia.org/wiki/Hard_link[hardlinking] 덕분에 클론들은 $ git commit -a -m "Description of my changes" $ git pull -다른 분들에게 당신의 작업을 공유하는 일은 그 쪽 분들이 쓰시는 버전 관리 시스템에 따라 다릅니다. 새로운 디렉토리는 당신이 작업한 파일들이 포함되어 있죠. 위의 명령어를 쓰신 후에 다른 버전 관리 프로그램에서 쓰는 명령어를 통해서 그들의 중앙 서버에 업로드 하실 수 있습니다. +다른 분들에게 당신의 작업을 공유하는 일은 그 쪽 분들이 쓰시는 VCS에 따라 다릅니다. 새로운 디렉토리는 이제 당신이 실행한 작업들이 포함되어 있겠죠. 위의 명령어를 쓰신 후에 다른 VCS에서 쓰는 명령어를 통해서 그들의 중앙 서버에 업로드 하실 수 있습니다. -Subversion은 가장좋은 중앙 버전 관리식 시스템으로써 개발자들 사이에서 애용되고 있습니다. Git에서 *git svn*을 사용해서 위에서 언급한 일들은 Subversion 저장소를 대상으로 행할 수 있습니다.http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[Git 프로젝트를 Subversion 저장소로 보내기]. +Subversion은 가장좋은 중앙관리식 VCS로써 개발자들 사이에서 애용되고 있습니다. Git에서 *git svn*을 사용해서 위에서 언급한 일들은 Subversion 저장소를 대상으로 행할 수 있습니다.http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[Git 프로젝트를 Subversion 저장소로 보내기]. === Mercurial === -Mercurial 역시 비슷한 버전 관리 시스템으로써 Git과 쉽게 연동될 수 있습니다. 'hg-git'플러그인을 통해서 Mercurial 유저들은 Git 저장소에 쉽게 밀어넣기 (push)와 당기기 (pull)을 사용할 수 있죠. +Mercurial 역시 비슷한 VCS으로써 Git과 쉽게 연동될 수 있습니다. 'hg-git'플러그인을 통해서 Mercurial 유저들은 Git 저장소에 쉽게 '밀어넣기 (push)'와 '당기기 (pull)'을 사용할 수 있죠. -Git으로 'hg-git'을 구하는 방법: +Git으로 'hg-git' 플러그인을 구하는 방법: $ git clone git://github.com/schacon/hg-git.git -Mercurial로 'hg-git'을 구하는 방법: +Mercurial로 'hg-git'플러그인을 구하는 방법: $ hg clone http://bitbucket.org/durin42/hg-git/ -하지만 Git에 이 것과 비슷한 플러그인이 있는지는 모르겠다. 그렇기 때문에 Mercurial보다는 Git을 주 저장소를 쓰길 선호한다. Mercurial로 프로젝트를 진행할 경우에는 대부분의 케이스에 한 자원봉사 개발자가 Git 저장소를 관리하는 업무를 떠 맡곤 합니다. 그러나 Git으로 Mercurial 프로젝트를 진행할 경우에는 'hg-git'플러그인의 도움으로 그러한 번거로움이 필요없을 것입니다. +유감스럽지만 다른 VCS에선 Git과 비슷한 플러그인이 있는지는 모르겠습니다. 그렇기 때문에 Mercurial보다는 Git을 주 저장소를 쓰길 선호합니다. Mercurial로 프로젝트를 진행할 경우에는 대부분 한 개발자가 Git 저장소를 같이 병행관리하는 업무를 떠맡곤 합니다. 그러나 Git으로 Mercurial 프로젝트를 진행할 경우에는 'hg-git'플러그인의 도움으로 그러한 번거로움이 필요없겠죠. -빈 저장소를 이용해서 Mercurial 저장소를 Git 저장소로 바꿀 수 있으나, 'hg-fast-export.sh'스크립트를 사용해 더 쉽게 이 작업을 끝낼 수 있습니다. 다음 저장소에서 이 스크립트를 구할 수 있습니다: +Mercurial에 있는 repository를 Git repository로 '밀어넣기 (push)'를 사용하여 쉽게 바꿀 수 있으나, 'hg-fast-export.sh'스크립트를 사용해 이 작업을 더 쉽게 끝낼 수 있습니다. 다음 저장소에서 이 스크립트를 구할 수 있습니다: $ git clone git://repo.or.cz/fast-export.git -빈 저장소에서 한 번 바꿔봅시다: +빈 저장소에서 이 작업을 한번 해봅시다: $ git init $ hg-fast-export.sh -r /hg/repo @@ -197,15 +189,18 @@ Mercurial로 'hg-git'을 구하는 방법: === Bazaar === -Bazaar는 Git과 Mercurial 다음으로 많이 알려진 버전 관리 시스템 입니다. +Bazaar는 Git과 Mercurial 다음으로 많이 알려진 VCS입니다. -Bazaar는 작업 수정을 하기 용이하게 디자인 되어있지요; 개발자들은 과거의 실수에서 배우고 무시해도 될만한 에러에서 자유롭습니다. 그리고 Bazaar를 사용하는 개발자들은 다른 버전 관리 시스템들에 관해 굉장히 개방적인 분들 일겁니다. +Bazaar는 만들어진지 별로 되지않은 시스템이기에 엄청난 가능성이 잠재하고 있지요; Bazaar 개발자들은 다른 VCS의 단점을 배우고 고쳐나가는 중입니다. 그리고 Bazaar 개발자들은 Bazaar VCS가 다른 VCS들과 연동하는 문제에 많은 노력을 기울이고 있습니다. -'bzr-git'플러그인은 Bazaar 이용자들이 Git 저장소를 통해 작업할 수 있도록 해줍니다. 'tailor' 프로그램은 Bazaar 저장소를 Git 저장소로 바꿔줍니다. 'bzr-fast-export'도 한 번 검색해보세요. +'bzr-git'플러그인은 Bazaar 이용자들이 Git과 함께 연동해 작업할 수 있도록 해줍니다. 'tailor' 프로그램은 Bazaar repository를 Git repository로 바꿔줍니다. 'bzr-fast-export'도 한 번 검색해보세요. === 내가 Git을 사용하는 이유 === -제가 Git을 처음에 사용했던 이유는 제가 듣기에 Git은 Linux kernel source 관리에 용이하다고 들었기 때문입니다. Git을 사용한 이후로는 다른 버전 관리 시스템으로 바꿔야겠다는 생각은 들지도 않았지요. Git은 저에게 유용한 도움이 되었으나, Git도 완벽한 플랫폼은 아닙니다. 저는 Linux를 주로 이용하기 때문에 -다른 플랫폼과의 문제는 생략하겠습니다. 그리고 저는 C, bash scripts, Python을 이용하는 사람이고 빠른 프로그램 시간에 목숨을 거는 사람 중 하나입니다. -Git이 어떻게 좀 더 발전할 수 있을지 Git과 비슷한 프로그램도 짜보기도 했지만 학교 프로젝트 정도로만 썻었을 뿐입니다. 그러나 제 프로젝트를 완료하더라도 저는 Git을 계속 이용했을 겁니다. 제 프로그램을 써도 별로 투자한 것에 비해 얻을 것이 적어보였기 때문이지요. +제가 Git을 처음에 사용했던 이유는 제가 듣기에 Git은 Linux kernel source 관리에 용이하다고 들었기 때문입니다. Git을 사용한 이후로는 다른 VCS로 바꿔야겠다는 생각은 들지도 않았지요. Git은 저에게 매우 유용했고 저는 아직 Git으로 인한 어떠한 심각한 오류를 겪어보지도 않았습니다.저는 Linux를 주로 이용하기 때문에 다른 플랫폼에서 발생할 수 있는 문제는 생략하겠습니다. + +그리고 저는 C, bash scripts, Python을 이용하는 사람이고 프로그램 런타임에 목숨을 거는 사람 중 하나입니다. + +Git이 어떻게 좀 더 발전할 수 있을지, 또 Git과 비슷한 프로그램도 직접 짜보기도 했지만 학교 프로젝트 정도로만 썻었을 뿐입니다. 그러나 제가 직접 저만의 VCS를 만들었더라도 저는 Git을 계속 이용했을 겁니다. 제 프로그램을 써도 별로 투자한 것에 비해 얻을 것이 적어보였기 때문이지요. + 자연스레 여러분들이 필요로하고 원하는 프로그램은 계속해서 바뀝니다. 그러나 Git과는 그럴 가능성이 매우 적지요. \ No newline at end of file diff --git a/ko/drawbacks.txt b/ko/drawbacks.txt index eab26681..2079dbb8 100644 --- a/ko/drawbacks.txt +++ b/ko/drawbacks.txt @@ -1,97 +1,93 @@ -== Appendix A: Git Shortcomings == +== 부록 A: Git의 약점들 == -There are some Git issues I've swept under the carpet. Some can be handled easily with scripts and hooks, some require reorganizing or redefining the project, and for the few remaining annoyances, one will just have to wait. Or better yet, pitch in and help! +Git을 소개하면서 저는 Git의 약점들을 몇 개 숨기긴 했습니다. 몇가지 약점들은 script나 hook을 통해 해결할수 있고, 몇가지는 프로젝트를 수정하면서 해결할수 있고, 그 외의 약점들은 현 시점에선 그냥 앉아서 기다리고 있을 수 밖에 없습니다. 그러기 싫으시다면 직접 도와줘보십쇼! -=== SHA1 Weaknesses === +=== SHA1 약점 === -As time passes, cryptographers discover more and more SHA1 weaknesses. Already, -finding hash collisions is feasible for well-funded organizations. Within -years, perhaps even a typical PC will have enough computing power to silently -corrupt a Git repository. +시간이 지나면 해커들은 SHA1의 약점들을 더 많이 발견하게 될겁니다. 이미 hash에서의 충돌을 찾아내는 건 +가능한 일이지요. 몇 년 안에는 Git repository를 위해할 수 있는 연산능력을 가진 +일반컴퓨터도 있을 수 있습니다. -Hopefully Git will migrate to a better hash function before further research -destroys SHA1. +Git이 그런 일이 일어나기전에 hash관련 기능들을 발전할 수 있었으면 좋겠어요. === Microsoft Windows === -Git on Microsoft Windows can be cumbersome: +Git을 Microsoft Windows에서 사용하는 건 성가실 수 있습니다: -- http://cygwin.com/[Cygwin], a Linux-like environment for Windows, contains http://cygwin.com/packages/git/[a Windows port of Git]. +- http://cygwin.com/[Cygwin], 리눅스와 비슷한 윈도우체제에선 http://cygwin.com/packages/git/[a Windows port of Git] 가 있습니다. -- http://code.google.com/p/msysgit/[Git on MSys] is an alternative requiring minimal runtime support, though a few of the commands need some work. +- https://gitforwindows.org/[Git for Windows] 는 아직 몇몇 허점이 있지만 Windows에서 Git을 효율적으로 쓸수 있게 해줍니다. -=== Unrelated Files === +=== Git과 연관없는 파일들 === -If your project is very large and contains many unrelated files that are constantly being changed, Git may be disadvantaged more than other systems because single files are not tracked. Git tracks changes to the whole project, which is usually beneficial. +만약에 당신의 프로젝트가 굉장히 크고, 쓸때없는 파일들이 많이 들어있는 상태이고, 상시로 바뀌는 상태라면, Git은 하나의 파일을 트랙킹하지 않기에 다른 VCS보다 유용하지 않을 수 있습니다. Git은 프로젝트 단위로 트랙킹을 하기 때문입니다. 이건 Git의 장점입니다. -A solution is to break up your project into pieces, each consisting of related files. Use *git submodule* if you still want to keep everything in a single repository. +그래도 만약 하나의 파일만을 트랙킹하기 원하다면 프로젝트를 여러개의 파트로 분리해두는 겁니다. 여러개의 파트로 분리해도 *git submodule* 명령어를 이용하면 하나의 repository를 유지할 수 있을겁니다. -=== Who's Editing What? === +=== 누가 어떤 작업을 하는거지? === -Some version control systems force you to explicitly mark a file in some way before editing. While this is especially annoying when this involves talking to a central server, it does have two benefits: +몇몇의 VCS는 유저들로 하여금 작업하기전에 파일들을 강제로 마킹 시킵니다. 이러한 강제성은 중앙서버와 연결하는데 귀찮은 절차이지만 두개의 장점이 있습니다: - 1. Diffs are quick because only the marked files need be examined. + 1. 버전의 차이 (Diff)를 체크하는데 매우 빠릅니다. 마킹 된 파일만 검사하면 되니까요. - 2. One can discover who else is working on the file by asking the central server who has marked it for editing. + 2. 유저는 어떤 사람이 어떤 작업을 하는지 중앙서버를 조회하면 간단히 알아낼 수 있습니다. -With appropriate scripting, you can achieve the same with Git. This requires cooperation from the programmer, who should execute particular scripts when editing a file. +Git으로도 이렇게 하는게 가능합니다. 그러나 그렇게 하기위해선 코딩이 좀 필요하니 프로그래머의 도움이 좀 필요할 수 있겠군요. -=== File History === +=== 파일 히스토리 === -Since Git records project-wide changes, reconstructing the history of a single file requires more work than in version control systems that track individual files. +Git은 프로젝트 전체를 트랙킹하기 때문에 어떤 한 파일의 히스토리를 재건설하는데 다른 (하나의 파일만 트랙킹하는) VCS들보다 느릴 수 있습니다. -The penalty is typically slight, and well worth having as other operations are incredibly efficient. For example, `git checkout` is faster than `cp -a`, and project-wide deltas compress better than collections of file-based deltas. +그렇게 심하게 느려진다는 것은 아니고 오히려 Git의 장점들이 이 하나의 단점을 상쇄하고도 남습니다. 예를 들어 'git checkout'은 'cp -a'보다 빠르고 프로젝트 전체의 변화를 압축화하는 것이 파일 하나하나씩 압축하는 것보다 효율적입니다. -=== Initial Clone === +=== 태초의 클론 === -Creating a clone is more expensive than checking out code in other version control systems when there is a lengthy history. +만약에 어떠한 프로젝트의 히스토리가 길 경우, 클론을 만드는 것은 다른 VCS들의 'checking out'보다 컴퓨터의 용량을 더 차지할 수 있습니다. -The initial cost is worth paying in the long run, as most future operations will then be fast and offline. However, in some situations, it may be preferable to create a shallow clone with the `--depth` option. This is much faster, but the resulting clone has reduced functionality. +그러나 길게보면 클론이 checking out보다 나을 것입니다. 클로닝 이후 다른 명령어들은 매우 빠르고 오프라인으로도 진행이 가능하니까요. 그러나 어떠한 경우에는 좀 더 히스토리가 얕은 클론을 '--depth' 명령어를 통해 만드는 것이 더 나은 선택일 수 있습니다. 이렇게 만들어진 클론은 작업실행 속도가 빠르겠지만 몇몇 기능들이 제외되어 있을 수 있습니다. -=== Volatile Projects === +=== 불완전한 프로젝트들 === -Git was written to be fast with respect to the size of the changes. Humans make small edits from version to version. A one-liner bugfix here, a new feature there, emended comments, and so forth. But if your files are radically different in successive revisions, then on each commit, your history necessarily grows by the size of your whole project. +Git은 파일에 작업을 더 많이할 수록 그 작업량에 대비해 빠르게 Version Control을 할 수 있도록 하기위해 쓰여진 프로그램입니다. 인간은 하나의 버전에서 다음 버전으로 작업을 할때 소량의 작업만 진행할 수 있죠. 예를들어, 한줄짜리 코드에 있는 버그를 고친다던가, 새로운 기능을 넣는다던가, 코멘트를 코드에 단다거나 말이죠. 그런데 만약 commit과 commit 사이에 작업량이 방대하게 클 경우 그 파일의 히스토리는 비례해서 커질 수 밖에 없겠죠. -There is nothing any version control system can do about this, but standard Git users will suffer more since normally histories are cloned. +VCS는 이것에 대해 아무것도 할 수 없습니다. 일반 Git 유저들은 그 부풀어진 파일들을 곧대로 받아들일 수 밖에 없겠죠. -The reasons why the changes are so great should be examined. Perhaps file formats should be changed. Minor edits should only cause minor changes to at most a few files. +그러나 왜 방대한 작업량이 필요했는지에 대해 알아볼 필요는 있습니다. 파일 포맷이 바뀌어서 그랬을수도 있죠. 소량의 작업은 소량의 변화를 주기마련입니다. -Or perhaps a database or backup/archival solution is what is actually being sought, not a version control system. For example, version control may be ill-suited for managing photos periodically taken from a webcam. +아니면 데이터베이스나 백업자료실를 구축해놓는 것이 이런 방대한 프로젝트들을 진행하는 데에 있어 VCS보다 적합할수도 있습니다. 예를 들어 VCS는 어떤 웹캠에서 주기적으로 찍은 이미지를 관리하는 데에는 적합하지 않습니다. -If the files really must be constantly morphing and they really must be versioned, a possibility is to use Git in a centralized fashion. One can create shallow clones, which checks out little or no history of the project. Of course, many Git tools will be unavailable, and fixes must be submitted as patches. This is probably fine as it's unclear why anyone would want the history of wildly unstable files. +만약에 파일들이 매번 변화하고 있고 각각의 변화에 무조건 버젼번호를 매겨야겠다 한다면 Git을 중앙서버처럼 쓰는 방법밖에 없습니다. 개발자들은 상대적으로 가벼운 클론을 만들면 되죠. 이렇게 일을 진해하면 물론 단점도 있을겁니다. 픽스들을 패치로 배포해야하고 Git tool들이 들어먹지 않을 수도 있어요. 근데 이렇게라도 일을 진행해야하는게 맞는 방법일 수 있습니다. 아무도 히스토리가 매우 긴 프로젝트들을 곧대로 받긴 싫어하거든요. -Another example is a project depending on firmware, which takes the form of a huge binary file. The history of the firmware is uninteresting to users, and updates compress poorly, so firmware revisions would unnecessarily blow up the size of the repository. +다른 예시로는 큰 바이너리 파일들을 수행하는 펌웨어들에 기반한 프로젝트를 진행할 경우입니다. 펌웨어의 히스토리는 유저들에게 별로 흥미로운 소재는 아니고, 업데이트들은 압축률이 매우 좋지 않습니다. 그래서 펌웨어들을 재구성할떄는 repository의 크기가 매우 커지는 경우가 있죠. -In this case, the source code should be stored in a Git repository, and the binary file should be kept separately. To make life easier, one could distribute a script that uses Git to clone the code, and rsync or a Git shallow clone for the firmware. +이럴때에는 모든 소스코드들이 Git repository에 저장되어 있는 편이 좋고, 바이너리 파일들은 따로 보관되어야 할 것 입니다. 이 일을 좀 더 쉽게 진행하기 위해서 Git 유저가 어떤 파일에 대해 클론을 만들수있고 *rsync*를 할 수 있으며, 가벼운 클론을 만들수있는 코드를 배포하는 것이 좋을 수 있습니다. -=== Global Counter === +=== 글로벌 카운터 === -Some centralized version control systems maintain a positive integer that increases when a new commit is accepted. Git refers to changes by their hash, which is better in many circumstances. +몇몇 중앙관리식 VCS들은 새로운 commit이 받아들여질때마다 임의의 양의정수를 보존합니다. Git은 양의정수보다 나은 hash를 써서 commit을 관리합니다. -But some people like having this integer around. Luckily, it's easy to write scripts so that with every update, the central Git repository increments an integer, perhaps in a tag, and associates it with the hash of the latest commit. +그러나 어느 사람들은 아직도 양의정수로 commit관리를 하길 추구합니다. 다행히도 Git에 추가프로그래밍을하여 Git repository에서 양의정수를 1씩 더하는 방식으로 commit을 관리할수도 있습니다. -Every clone could maintain such a counter, but this would probably be useless, since only the central repository and its counter matters to everyone. +어느 클론 파일이나 양의정수를 사용하여 commit을 관리할 수 있습니다. 그러나 이건 아무짝에도 쓸모가 없죠. 중앙 repository만 이 숫자를 쓸꺼니까요. -=== Empty Subdirectories === +=== 빈 (empty) 섭디렉토리 === -Empty subdirectories cannot be tracked. Create dummy files to work around this problem. +빈 섭디렉토리는 트랙킹되지 않습니다. 그러나 더미 파일을 만들어서 트랙킹하게 편법을 쓸 수 있죠. -The current implementation of Git, rather than its design, is to blame for this drawback. With luck, once Git gains more traction, more users will clamour for this feature and it will be implemented. +현 버전의 Git으로써 이 문제점은 Git의 약점입니다. Git이 다시 수면위로 올라가고 더 많은 사람들이 사용하게 될수록 이런 약점도 메꿔나가 지겠죠. -=== Initial Commit === +=== 태초의 commit === -A stereotypical computer scientist counts from 0, rather than 1. Unfortunately, with respect to commits, git does not adhere to this convention. Many commands are unfriendly before the initial commit. Additionally, some corner cases must be handled specially, such as rebasing a branch with a different initial commit. +보통의 컴퓨터공학자들은 숫자를 셀 때 0부터 세지 1부터 세지 않습니다. 하지만 안타깝게도 commit의 횟수를 셀때 git은 컴퓨터공학자들처럼 숫자를 세지 않습니다. Git의 그 많은 명령어들은 commit이 태초적으로 한번 이루어지기 전까지는 실행되지 않을겁니다. Branch들을 rebasing 할때나 이럴 경우에는 예외일 수도 있습니다. -Git would benefit from defining the zero commit: as soon as a repository is constructed, HEAD would be set to the string consisting of 20 zero bytes. This special commit represents an empty tree, with no parent, at some time predating all Git repositories. +애초에 Git은 태초의 commit으로부터 많은 혜택을 받습니다: repostiory가 생성되자마자 HEAD는 20 zero bytes의 스트링으로 자동설정됩니다. 이 특별한 commit은 빈 나무로 표현합니다. 빈 나무는 부모님 commit도 없습니다. 한마디로 근본이 없는 친구를 태초의 commit으로 부릅니다. -Then running git log, for example, would inform the user that no commits have been made yet, instead of exiting with a fatal error. Similarly for other tools. +그리고 태초의 commit후, git log를 로드했을때 Git이 오류를 내지 않고 단순히 commit이 하나도 안 되었다고 알려줄 것입니다. -Every initial commit is implicitly a descendant of this zero commit. +태초의 commit은 한마디로 zero commit의 양자같은 컨셉트입니다. -However there are some problem cases unfortunately. If several branches with different initial commits are merged together, then rebasing the result requires substantial manual intervention. +그러나 이런 구성은 가끔 문제를 야기합니다. 여러개의 branch가 모두 태초의 commit을 하고 이제 branch를 병합시켜야 할때, rebasing은 아마 유저 본인이 수동으로 버전청소를 하라고 할수도 있습니다. -=== Interface Quirks === +=== 별난 인터페이스 === -For commits A and B, the meaning of the expressions "A..B" and "A...B" depends -on whether the command expects two endpoints or a range. See *git help diff* -and *git help rev-parse*. +A와 B commit이 있을때, "A..B" 와 "A...B" 표현의 차이는 명령어가 두개의 종점이나 범위가 입력되기를 기다리고 있느냐 마느냐입니다. *git help diff* 와 *git help rev-parse*를 참조하십시오. diff --git a/ko/grandmaster.txt b/ko/grandmaster.txt index 783ace00..f8cc00e6 100644 --- a/ko/grandmaster.txt +++ b/ko/grandmaster.txt @@ -1,11 +1,9 @@ == Git 마스터링 == 지금까지 배운것만으로도 당신은 *git help* 페이지를 자유롭게 돌아다니며 거의 모든 것을 -이해할 수 있을 것입니다. 그러나 어떠한 문제를 풀기위해 어느 한 가지의 알맞는 명령어를 찾는 것은 -아직 어려울 수 있습니다. 그런 문제에 대해 제가 도와줄 수 있을 것 같습니다: 아래는 제가 Git을 -사용하며 유용하게 썼던 몇가지 팁들입니다. +이해할 수 있을 것입니다. 그러나 어떠한 문제를 풀기위해 어느 한 가지의 알맞는 명령어를 찾는 것은 아직 성가실 수 있습니다. 그런 문제에 대해 제가 도와줄 수 있을 것 같습니다: 아래는 제가 Git을 사용하며 유용하게 썼던 몇가지 팁들입니다. -=== 소스 공개 === +=== 소스 배포 === 제 프로젝트에서 Git은 제가 저장 및 공개하고 싶은 파일들을 정확히 추적하여 줍니다. @@ -19,9 +17,9 @@ Git에게 무엇을 추가, 삭제 및 파일이름을 바꾸었는지 일일히 $ git add . $ git add -u -Git은 현재 작업중인 디렉토리에 있는 파일들을 자동으로 살피며 자세한 사항들을 기록합니다. 위의 두번째 +Git은 현재 작업중인 디렉토리에 있는 파일들을 자동으로 살피며 자세한 사항들을 기록하여 줍니다. 위의 두번째 명령어 (git add -u) 대신에 'git commit -a'를 사용하여 그 명령어와 commit을 동시에 -해낼 수 있습니다. *git help ignore*를 참고하여 어떠한 지정된 파일을 무시하는 방법을 +해낼 수 있습니다. *git help ignore*를 참고하여 특별히 지정된 파일을 무시하는 방법을 알아보십시오. 위의 모든 것을 한 줄의 명령어로 실행할 수 있습니다. @@ -49,30 +47,29 @@ Commit을 한지 시간이 좀 많이 지난 상황입니까? 코딩을 너무 $ git commit -위의 간단한 명령어를 사용하여 부분적인 commit을 실행합니다. 이 상황에선 반드시 *-a*옵션을 생략하시길 바랍니다. +위의 간단한 명령어를 사용하여 직접 선택한 작업만을 commit합니다. 이 상황에선 반드시 *-a*옵션을 생략하시길 바랍니다. 그렇지 않으면 Git은 모든 수정작업을 commit할 것입니다. 만약에 여러군데 다른 디렉토리에 많은 수정작업을 해놓았다면 어떻게 할까요? 수정된 사항을 하나씩 검토하는 작업은 정말 귀찮은 짓입니다. 이럴땐 *git add -i*를 사용합니다. 몇 번의 타이핑만으로도 특정 파일의 수정작업을 검토할 수 있게됩니다. 또는 *git commit \--interactive*를 사용하여 작업 중 -자동으로 commit하는 방법도 있을 수 있습니다. +자동으로 작업 후 commit하는 방법도 있을 수 있습니다. === 인덱스: Git의 스테이징 구역 === -여태까지 Git의 유명한 기능인 'index'를 피해왔지만 이제 한 번 살펴본 시간이 온 것 같습니다. +여태까지 Git의 중요한 기능인 'index'를 피해왔지만 이제 한 번 살펴본 시간이 온 것 같습니다. 인덱스는 임시적인 스테이징 구역 (번역주:책갈피처럼)으로 보면 됩니다. Git은 당신의 프로젝트와 프로젝트의 -기록 사이에 데이터를 직접 옮기는 경우는 드뭅니다. 대신, Git은 인덱스에 파일을 쓰며 그리고 그 파일들을 -마지막 목표지점에 카피하여 줍니다. +기록 사이에 데이터를 직접 옮기는 경우는 드뭅니다. 대신, Git은 인덱스에 파일을 쓰며 그리고 그 파일들을 마지막 목표지점에 카피하여 줍니다. -예를 들어 *commit -a*는 원래 투-스텝 과정을 거치는 하나의 명령어입니다. 첫번째로는 현 작업상황의 -스냅샷을 찍어 모든 파일들을 인덱스하는 과정을 거칩니다. 두번째 과정에서는 방금 찍은 스냅샷을 영구적으로 +예를 들어 *commit -a*는 원래 두단계 과정을 거치는 하나의 명령어입니다. 첫번째 단계에서는 현 작업상황의 +스냅샷을 찍어 모든 파일들을 인덱스하는 과정을 거칩니다. 두번째 단계에서는 방금 찍은 스냅샷을 영구적으로 보관하게 됩니다. *-a* 옵션을 쓰지않고 commit을 하는 것은 이 두번째 과정만 실행하는 일입니다. 그렇기에 *git add* 같은 명령어를 쓴 후에 commit을 하는 것이 당연한 이야기가 되겠지요. 대체적으로 인덱스에 관한 컨셉트는 무시하고 파일기록에서 직접적으로 쓰기와 읽기가 실행된다는 개념으로 이해하면 편합니다. 이런 경우에는 우린 인덱스를 제어하는 것 처럼 좀 더 세부한 제어를 하기 원할것입니다. 부분적인 스냅샷을 찍은 후 영구적으로 이 '부분스냅샷'을 보존하는 것이죠. -=== 대가리(HEAD)를 잃어버리지 않기 === +=== 머리(HEAD)를 잃어버리지 않기 === HEAD 태그는 문서작업시 보이는 커서처럼 마지막 commit 포인트를 가르키는 포인터 역할을 합니다. Commit을 실행할 때마다 물론 HEAD도 같이 앞으로 움직이겠지요. 어떤 Git 명령어들은 수동으로 HEAD를 움직일 수 있게 해줍니다. 예를 들면: @@ -82,7 +79,7 @@ HEAD 태그는 문서작업시 보이는 커서처럼 마지막 commit 포인트 위 명령어를 사용한다면 HEAD를 commit을 3번 하기 전으로 옮깁니다. 이 후 모든 Git 명령어는 가지고 있던 파일은 현재상태로 그대로 두되 그 3번의 commit을 하지 않은 것으로 이해하죠. -그러나 어떻게 해야 다시 미래로 돌아갈 수 있을까요? 예전에 했던 commit들은 미래에 대해서 아무것도 모를텐데 말이지요. +그러나 어떻게 해야 다시 가장 최근으로 돌아갈 수 있을까요? 예전에 했던 commit들은 미래에 대해서 아무것도 모를텐데 말이지요. 원래의 HEAD의 SHA1을 가지고 있다면: @@ -97,11 +94,11 @@ HEAD 태그는 문서작업시 보이는 커서처럼 마지막 commit 포인트 ORIG_HEAD로 돌아가는 것만으로는 충분하지 않을지도 모릅니다. 당신은 방금 엄청나게 큰 실수를 발견하였고 아주 오래전에 했던 commit으로 돌아가야 할지 모릅니다. -기본적으로 Git은 나뭇가지를 수동으로 삭제하였더라도 2주의 시간동안 commit을 무조건 저장하여 둡니다. +기본적으로 Git은 branch를 수동으로 삭제하였더라도 2주의 시간동안 commit을 무조건 저장하여 둡니다. 문제는 돌아가고 싶은 commit의 hash를 찾는 일입니다. '.git/objects'의 모든 hash 값을 조회하여 얻어걸릴 때까지 해보는 방법이 있긴합니다만, 여기 좀 더 쉬운 방법이 있습니다. -Git은 모든 commit의 hash를 '.git/logs'에 저장해 둡니다. 하위 디렉토리 'refs'은 모든 나뭇가지의 활동기록을 저장하여두고 동시에 'HEAD'파일은 모든 hash 값을 저장하고 있습니다. +Git은 모든 commit의 hash를 '.git/logs'에 저장해 둡니다. 하위 디렉토리 'refs'은 모든 branch의 활동기록을 저장하여두고 동시에 'HEAD'파일은 모든 hash 값을 저장하고 있습니다. 후자는 실수로 마구 건너 뛴 commit들의 hash도 찾을 수 있게 해줍니다. reflog 명령어는 당신이 사용하기 쉬운 유저인터페이스로 log파일들을 표현하여 줍니다. 다음 명령어를 사용하여 보십시오. @@ -118,7 +115,7 @@ hash를 reflog으로부터 자르고 붙여넣기 보다는: 좀 더 많은 정보는 *git help rev-parse*의 "재편집 구체화하기" 섹션을 참고하십시오. -Commit의 2주의 생명을 연장하여 줄 수 있습니다. 예를 들어: +아까 언급한 commit의 2주살이 생명을 수동으로 연장하여 줄 수 있습니다. 예를 들어: $ git config gc.pruneexpire "30 days" @@ -134,7 +131,7 @@ Commit의 2주의 생명을 연장하여 줄 수 있습니다. 예를 들어: === Git을 좀 더 발전시키는 방법 === 진정한 UNIX와 같이 Git의 디자인은 다른 프로그램들의 GUI, 웹 인터페이스와 같은 하위파트들과 호환이 됩니다. 어느 Git 명령어들은 유명인사의 어깨위에 서있는 것처럼 -Git 그 자체가 스크립팅 언어로 사용될 수도 있습니다. 조금만 시간을 투자하면 Git은 당신의 선호에 더 알맞게 바꿀수 있습니다. +Git 그 자체가 스크립팅 언어로 사용될 수도 있습니다. 조금만 시간을 투자하면 Git은 당신의 기호에 더 알맞게 바꿀수 있습니다. 한 가지 트릭을 소개하자면 자주 사용할것 같은 명령어들을 짧게 만들어줄 수 있는 방법이 있습니다: @@ -143,12 +140,12 @@ Git 그 자체가 스크립팅 언어로 사용될 수도 있습니다. 조금 alias.co checkout $ git co foo # 'git checkout foo'와 같은 것입니다. -또 다른 트릭은 현재 작업중인 나뭇가지의 이름을 작업표시창에 표시하여주는 명령어도 있습니다. +또 다른 트릭은 현재 작업중인 branch의 이름을 작업표시창에 표시하여주는 명령어도 있습니다. $ git symbolic-ref HEAD -위 명령어는 현재 작업중인 나뭇가지 이름을 표기하여 줍니다. 실용적으로는 "refs/heads/"를 사용하지 않으며 -잠재적으로 일어날 수 있는 에러들을 무시하여 줍니다: +위 명령어는 현재 작업중인 branch 이름을 표기하여 줍니다. 실제로는 "refs/heads/"를 없애고 +잠재적으로 일어날 수 있는 에러들을 무시하는걸 추천드립니다: $ git symbolic-ref HEAD 2> /dev/null | cut -b 12- @@ -156,7 +153,7 @@ Git 그 자체가 스크립팅 언어로 사용될 수도 있습니다. 조금 시간이 지나면 이곳에 있는 툴들은 공식적으로 인정받아 고유명령어가 생기기도 하겠지요. Debian과 Ubuntu에서는 이 디렉토리는 +/usr/share/doc/git-core/contrib+에 위치하고 있습니다. -앞으로 +workdir/git-new-workdir+디렉토리에 방문할 일도 많을 것입니다. 시스템링크 기술을 통해서 이 스크립트는 원래의 저장소와 작업기록을 같이하는 +앞으로 +workdir/git-new-workdir+디렉토리에 방문할 일도 많을 것입니다. 시스템링크 기술을 통해서 이 스크립트는 원래의 repository와 작업기록을 공유하는 새로운 작업 디렉토리를 생성하여 줍니다: $ git-new-workdir an/existing/repo new/directory @@ -180,7 +177,7 @@ Git은 요즘 유저들이 데이터를 쉽게 지우지 못하도록 하고 있 $ git reset --hard 1b6d -*Branch*: 방금한 작업을 잃어버릴 것같으면 Git은 나뭇가지가 지워지지 않게합니다. 그래도 하고싶다면: +*Branch*: 방금한 작업을 잃어버릴 것같으면 Git은 branch가 지워지지 않게합니다. 그래도 하고싶다면: $ git branch -D dead_branch # -d 대신 -D @@ -203,15 +200,15 @@ Git은 요즘 유저들이 데이터를 쉽게 지우지 못하도록 하고 있 === 원치않는 commit들을 방지하기 === -바보같은 실수들은 내 저장소를 망쳐놓곤 합니다. 그 중에서도 제일 무서운 것은 *git add*를 쓰지 않아서 +바보같은 실수들은 내 repository를 망쳐놓곤 합니다. 그 중에서도 제일 무서운 것은 *git add*를 쓰지 않아서 작업해놓은 파일들을 잃어버리는 것이지요. 그나마 코드 뒤에 빈 공간을 마구 넣어놓는다던지 병합에서 일어날 수 있는 문제들을 해결해 놓지않는 것은 애교로 보입니다: 별로 문제가 되는 것들은 아니지만 -남들이 볼 수 있는 공공저장소에서는 보여주기 싫습니다. +남들이 볼 수 있는 repository에서는 보여주기 싫습니다. _hook_ 을 사용하는 것과 같이 제가 바보같은 짓을 할 때마다 경고를 해주는 기능이 있다면 얼마나 좋을까요: $ cd .git/hooks - $ cp pre-commit.sample pre-commit # Older Git versions: chmod +x pre-commit + $ cp pre-commit.sample pre-commit # 예전 Git 버젼에서는: chmod +x pre-commit 이제는 아까 설명했던 애교스러운 실수들이 발견될 때 Git은 commit을 도중에 그만 둘것입니다. @@ -223,6 +220,6 @@ _hook_ 을 사용하는 것과 같이 제가 바보같은 짓을 할 때마다 exit 1 fi -많은 git 작업들은 hook과 상호작용합니다; *git help hooks*를 참조하십시오. 우리는 Git over HTTP를 설명할때 +많은 git 작업들은 hook과 상호작용합니다; *git help hooks*를 참조하십시오. 우리는 "HTTP를 통한 Git"을을 설명할때 *post-update* hook을 활성화시켰습니다. HEAD가 옮겨질때마다 같이 실행되지요. Git over HTTP 예제에서는 post-update 스크립트가 통신에 필요한 Git을 업데이트 했었습니다. diff --git a/ko/history.txt b/ko/history.txt index 68e87a3a..d16c023d 100644 --- a/ko/history.txt +++ b/ko/history.txt @@ -1,52 +1,42 @@ -== 기록공부 == +== 히스토리 레슨 == -분산 관리 시스템을 택한 Git은 개발자들이 전 버전에서의 작업을 더 용이하게 할 수 있게 -도와주었습니다. 그러나 프로그램의 과거를 들춰내려면 조심하세요: 당신이 소유하고 있는 파일들만 -다시쓰기 하세요. 세계 각국의 나라들이 누가 어떤 잘못을 했는지 끝임없이 따지는 것처럼 -만약 한 개발자가 당신이 가지고 있는 파일과 기록 (history)이 다른 파일들을 클론하여 갔을 때 -병합할때 문제가 생길지도 모릅니다. +분산관리식 시스템을 택한 Git은 개발자들이 history관리를 용이하게 할 수 있게 해줍니다. 그러나 프로그램의 과거를 들춰내려면 조심하세요: 당신이 소유하고 있는 파일들만 다시쓰기 하세요. 세계 각국의 나라들이 누군가 어떤 잘못을 하나하면 누가했는지 끝임없이 따지는 것처럼 만약 한 개발자가 당신이 가지고 있는 파일과 기록 (history)이 다른 파일들을 클론하여 갔을 때 추후 병합시 문제가 생길지도 모릅니다. -어떤 개발자들은 파일의 기록은 절대로 바뀌면 안되는 것이라고 믿고 있습니다. -또 어떤 개발자들은 수정 기록들이 깨끗하게 정리되어야 한다고 합니다. -Git은 이렇게 다른 성향의 개발자들을 모두 포용할 수 있습니다. 클로닝, 나뭇가지, 병합과 같은 -기능들과 같이 파일의 기록들을 바꾸는 것은 Git이 할 수있는 많은 기능들 중에 하나일 뿐입니다. -어떻게 영리하게 사용하는지는 당신에게 달려있죠. +어떤 개발자들은 파일의 수정기록들이 절대로 조작되면 안되는 것이라고 믿고 있습니다. 반면에 어떤 개발자들은 수정 기록들이 깨끗하게 정리되어 보여져야 할 것만 선택하여 보여져야 한다고 합니다. +Git은 이렇게 다른 성향의 개발자들을 모두 포용할 수 있습니다. 클로닝, branch, 병합과 같은 기능들이 당신이 어떤 개발자 타입이던 당신의 일처리를 도와줄 것입니다. 어떻게 영리하게 사용하는지는 당신에게 달려있죠. === 오류 수정합니다 === -방금 commit을 했는데, 그 commit 메세지를 바꾸고 싶다고요? 그렇다면: +방금 commit을 했는데, 그 commit에 달린 메세지를 바꾸고 싶다고요? 그렇다면: $ git commit --amend 위 명령어를 사용하면 마지막으로 한 commit의 메세지를 바꿀 수 있습니다. 파일을 더하는 것을 잊어버리고 commit을 했다고요? *git add*를 사용하고서 위의 명령어를 사용하세요. -마지막으로 했던 commit에 편집을 더 하고 싶으신가요? 그렇다면 편집 후에 다음 명령어를 쓰세요. +마지막으로 했던 commit에 편집을 더 하고 싶으신가요? 그렇다면 작업 후에 다음 명령어를 쓰세요. $ git commit --amend -a === ... 더 있습니다 === -전에 보았던 문제가 10배 더 힘들었다고 생각합니다. 긴 시간동안 작업해서 많은 -commit을 하였다고 가정합니다. 그러나 당신은 그 commit들의 난잡한 구성이 마음에 들지 -않습니다. 그리고 어떤 commit 메세지들은 다시쓰고 싶습니다. 그렇다면: +이제 전보다 더 꼬인 상황을 마주했다고 생각합시다. 우선 당신이 긴 시간동안 작업해서 많은 +commit을 하였다고 가정해봅시다. 그러나 당신은 그 commit들의 난잡한 구성이 마음에 들지 +않습니다. 그리고 몇몇 commit 메세지들을 다시쓰고 싶다면: $ git rebase -i HEAD~10 -위 명령어를 사용한다면 당신이 좋아하는 작업용 에디터에 지난 열 개의 commit이 출력될 것입니다. 샘플을 보자면: +위 명령어를 사용한다면 당신의 작업용 에디터에 지난 열 개의 commit이 출력될 것입니다. 샘플을 보자면: pick 5c6eb73 Added repo.or.cz link pick a311a64 Reordered analogies in "Work How You Want" pick 100834f Added push target to Makefile -여기서는 오래된 commit이 'log' 명령어와 달리 새로운 commit보다 먼저 출력되어 나옵니다. -여기서는 5c6eb73 가 가장 오래된 commit이고 100834f이 가장 최근 commit 이죠. 그리고: -Here, 5c6eb73 is the oldest commit, and 100834f is the newest. Then: +여기서는 'log'와는 달리 가장 오래된 commit 부터 가장 최근의 commit의 순서로 나열되어 출력되었습니다.여기서는 5c6eb73 가 가장 오래된 commit이고 100834f이 가장 최근 commit 이죠. 그리고: -- 한 줄을 지움으로써 commit을 삭제합니다. 'revert' 명령어와 같으나 기록에는 남지 않게 지웁니다. - 이 전략은 마치 commit이 처음부터 존재하지 않던 것처럼 보여지게 해줍니다. -- 행들을 재정렬하며 commit의 순서를 바꾸어 줍니다. -- 'pick' 명령어 대신에 +- 한 줄을 지움으로써 commit을 삭제합니다. 'revert' 명령어와 비슷하지만 기록에는 남지 않게 지웁니다: 이 방법은 마치 commit이 처음부터 존재하지 않던 것처럼 보여지게 해줍니다. +- Commit list를 재정렬하며 commit의 순서를 바꾸어 줍니다. +- 위의 'pick' 명령어 대신에 * `edit` 을 사용하여 개정시킬 commit을 마킹합니다. * `reword`를 사용하여 로그메세지를 바꿉니다. * `squash` 를 사용하여 전에 했던 commit과 합병합니다. @@ -58,13 +48,12 @@ Here, 5c6eb73 is the oldest commit, and 100834f is the newest. Then: squash a311a64 Reordered analogies in "Work How You Want" pick 100834f Added push target to Makefile -저장 후 프로그램을 종료하면, Git은 a311a64를 5c6eb73로 병합시킵니다. *squash* (짓누르기)는 현 -작업을 다음 commit으로 밀어붙어버린다고 생각하시면 됩니다. +저장 후 프로그램을 종료하면, Git은 a311a64를 5c6eb73로 병합시킵니다. *squash* (짓누르기)는 지정된 commit을 바로 다음 commit으로 밀어붙어버린다고 생각하시면 됩니다. -Git은 로그메세지들도 합친후 나중에 편집할 수 있게 해줍니다. *fixup* 명령어를 -사용하면 이런 절차를 하지않아도 됩니다; 짓눌려진 로그메세지들은 간단히 삭제되기 때문입니다. +또, Git은 로그메세지들을 합친후 나중에 편집할 수 있게 해주기도 합니다. *fixup* 명령어를 +사용하면 이런 절차를 하지않아도 됩니다; 짓눌려진 (squash 된) 로그메세지들은 간단히 삭제되기 때문입니다. -*edit*을 이용하여 commit을 마킹해두었다면, Git은 같은 성향의 commit들 중에 가장 +*edit*을 이용하여 어떤 commit을 마킹해두었다면, Git은 같은 성향의 commit들 중에 가장 오래전에 했던 commit의 작업상태로 당신을 되돌려 보냅니다. 이 상태에서 아까 전 말했듯이 편집작업을 할 수도 있고, 그 상태에 맞는 새로운 commit을 만들수도 있습니다. 모든 수정작업이 만족스럽다면 다음 명령어를 사용해 앞으로 감기를 실행할 수 있습니다.: @@ -73,7 +62,7 @@ Git은 로그메세지들도 합친후 나중에 편집할 수 있게 해줍니 Git은 다음 *edit*까지 아니면 아무런 *edit*이 없다면 현재 작업상태까지 commit을 반복실행 할것입니다. -새로운 평가기준 (rebase)을 포기할 수도 있습니다: +새로운 rebase를 포기할 수도 있습니다: $ git rebase --abort @@ -81,15 +70,14 @@ Git은 다음 *edit*까지 아니면 아무런 *edit*이 없다면 현재 작업 === 로컬에서의 수정작업 === -어떤 프로젝트를 진행하고 있습니다. 당신의 컴퓨터에서 로컬 commit을 하다가 -이제 공식적인 프로젝트 파일들과 동기화 해야합니다. 이런 절차는 서버의 파일에 올리기전에 거쳐야 할 과정이지요. +어떤 프로젝트를 진행하고 있습니다. 당신의 컴퓨터에서 commit을 하며 작업을 하다가 +이제 공식적인 프로젝트 파일들이 있는 branch와 동기화 해야합니다. 이런 절차는 메인 branch에 올리기전에 거쳐야 할 과정이지요. -그러나 당신의 로컬 Git클론은 공식적인 파일기록와 개인으로 만든 파일기록이 뒤죽박죽 섞여있을 것입니다. 아무래도 공식적인 기록과 개인적인 기록이 분류되어 출력되면 기록을 확인하기가 쉽겠지요. +그러나 당신의 로컬 Git클론은 당신 혼자만 이해할 수 있는 수많은 기록이 뒤죽박죽 섞여있을 것입니다. 아무래도 개인적인 기록이 깨끗하게 정리되어 공식적인 기록만 볼 수 있게 된다면 좋겠지요: -위에서 설명했듯이 *git rebase* 명령어가 이 작업을 해줄것입니다. *--onto* 플래그를 사용할 -수도 있습니다. +위에서 설명했듯이 *git rebase* 명령어가 이 작업을 해줄것입니다. *--onto* 플래그를 사용하여 상호작용을 피할수도 있습니다. -*git help rebase*를 확인해서 좀 더 자세한 예를 한번 봐보세요. Commit을 분류할 수 있다는 걸 알게될 것입니다. 나뭇가지를 재정리할 수도있죠. +*git help rebase*를 확인해서 좀 더 자세한 예를 한번 봐보세요. Commit을 나눌 수 있다는 걸 알게될 것입니다. 여러 branch들을 재정리할 수도있죠. *rebase*는 유용한 명령어입니다. 여러가지 실험을 하기전에 *git clone*으로 복사본을 만들어두고 놀아보세요. @@ -98,10 +86,9 @@ Git은 다음 *edit*까지 아니면 아무런 *edit*이 없다면 현재 작업 가끔은 어떤 그룹사진에서 포토샵으로 몇 사람지우는 기능과 같은 명령어가 필요할지도 모릅니다. 스탈린식 스타일로 사람을 무자비하게 지우는 명령어 말입니다. 예를들어 -이제 어떤 프로젝트를 풀 시간이 왔다고 가정합니다. 그러나 어떤 파일들은 -다른 사람들이 보지 못하도록 하고싶습니다. 당신 크레딧카드 번호를 실수로 썻다던지 이런 실수를 -한다면 더욱 더 그러고 싶겠지요. 예전 commit으로 파일을 부분적으로 복구하는 것이 -가능하기 때문에 파일을 지우는 것으로는 부족합니다. 당신은 이 파일을 모든 +이제 어떤 프로젝트를 대중에게 공개할 시간이 왔다고 가정합니다. 그러나 어떤 파일들은 +일반 유저들이 보지 못하도록 하고싶습니다. 당신 크레딧카드 번호를 실수로 썻다던지 +했다면 더욱 더 그러고 싶겠지요. 이런 경우, 파일을 지우는 것 만으로는 부족합니다. 예전 commit으로 파일을 지워진 파일을 복구하는 것이 가능하기 때문이죠. 당신은 이 파일을 모든 commit으로 부터 없에야 할 것입니다: $ git filter-branch --tree-filter 'rm top/secret/file' HEAD @@ -110,20 +97,19 @@ commit으로 부터 없에야 할 것입니다: 제시하여 줄 것입니다. 대체적으로 *filter-branch*은 하나의 명령어만으로도 대량의 파일기록을 변화시킬 수 있을 것입니다. - 그리고 +.git/refs/original+ 디렉토리는 이렇게 만든 변화가 오기 전의 기록을 보여줄 것입니다. *filter-branch* 명령어가 어떻게 작용했는지 확인할수도 있고, 이 디렉토리를 지운다면 더 많은 *filter-branch*명령어를 실행시킬 수 있습니다. + 그리고 +.git/refs/original+ 디렉토리는 이렇게 만든 변화가 오기 전의 기록을 보여줄 것입니다. *filter-branch* 명령어가 어떻게 작용했는지 확인하고, 필요하다면 이 디렉토리를 지우면 됩니다. -마지막으로, 나중에 새로운 버전에서 작업을 진행하고 싶다면 당신의 클론을 새로운 버전의 클론으로 바꾸시면 됩니다. +마지막으로, 당신의 클론을 새로운 버전의 클론으로 바꾸시면 됩니다. === 기록 만들기 === [[makinghistory]] -프로젝트를 Git으로 옮겨오고 싶다고요? 다른 버전 관리 시스템에서 옮겨오는 것이라면, 어떤 개발자가 이미 프로젝트의 기록을 Git으로 옮겨오는 스크립트를 써두었을지도 모릅니다. +어떤 프로젝트를 Git으로 옮겨오고 싶다고요? 다른 VCS에서 옮겨오는 것이라면, 어떤 개발자가 이미 프로젝트의 기록을 Git으로 쉽게 옮겨오는 스크립트를 써두었을지도 모릅니다. 아니라면, 특정 포맷으로 텍스트를 읽어 Git 기록을 처음부터 작성하여 주는 -*git fast-import* 명령어를 사용해서 확인해 보세요. 대체적으로 기록 스크립트는 -한번에 간편하게 이 명령어를 사용해서 만들어졌을 것입니다. +*git fast-import* 명령어를 확인해 보세요. 대체적으로 한번에 간편하게 프로젝트를 Git에서 사용할수 있게 해줄겁니다. -예로, '/tmp/history' 같은 임시파일에 다음 텍스트를 붙여넣기 해보세요: +예를들어, '/tmp/history' 같은 임시파일에 다음 텍스트를 붙여넣기 해보세요: ---------------------------------- commit refs/heads/master committer Alice Thu, 01 Jan 1970 00:00:00 +0000 @@ -160,7 +146,7 @@ EOT ---------------------------------- -그리고 Git 저장소를 만들어보세요: +그리고 이 임시파일로 Git repository를 만들어보세요: $ mkdir project; cd project; git init $ git fast-import --date-format=rfc2822 < /tmp/history @@ -169,10 +155,10 @@ EOT $ git checkout master . -*git fast-export* 명령어는 아무 Git 저장소를 결과물이 사람들이 읽을 수 +*git fast-export* 명령어는 아무 Git repository를 결과물이 사람들이 읽을 수 있는 포맷으로 바꾸어 주는 *git fast-import* 포맷으로 바꾸어 줍니다. 이 명령어들은 텍스트 파일들을 텍스트 파일 전용채널을 통해서 -저장소로 밀어넣기 해줍니다. +repository로 밀어넣기 해줍니다. === 어디서부터 잘못되었을까? === @@ -185,12 +171,11 @@ EOT $ git bisect bad HEAD $ git bisect good 1b6d -Git에서 한 프로젝트를 반 (good과 bad) 으로 나누어서 테스팅을 실행합니다. 그리고 아직도 버그가 발견된다면: +Git에서 한 프로젝트를 자체적으로 테스팅을 실행합니다. 그리고 버그가 발견된다면: $ git bisect bad -버그가 더이상 없다면 위 명령어에서 "bad"를 "good"으로 바꾸세요. Git은 good 버전과 bad 버전 사이로 -당신을 데려갑니다. 물론 버그를 찾을 확률은 높아지지요. 몇 번이렇게 반복하다보면 +버그가 더이상 없다면 위 명령어에서 "bad"를 "good"으로 바꾸세요. Git은 good 버전과 bad 버전 사이로 당신을 데려갈 겁니다. 물론 버그를 찾을 확률은 높아지지요. 몇 번이렇게 반복하다보면 결국엔 버그를 일으킨 commit을 찾아낼 수 있게 도와줄 것입니다. 버그찾기를 완료했다면 다시 처음 작업상태로 (이젠 버그가 없겠지요) 돌아가야 겠지요: @@ -206,51 +191,46 @@ Git에서 한 프로젝트를 반 (good과 bad) 으로 나누어서 테스팅을 이분화 (bisect)를 강제종료하지요. 당신은 이것보다 더 많은 일을 할 수 있습니다. 도움말은 이분화를 시각화해주는 방법과, - 이분화 기록을 다시보는 방법, 확인된 이상없는 변화들은 건너띄어 테스팅을 가속 시켜주는 기능들을 - 배우실 수 있습니다. + 이분화 기록을 다시보는 방법, 이미 확인된 이상없는 변화들은 건너띄어 테스팅을 가속 시켜주는 기능들을 배우실 수 있습니다. === 누가 망가뜨렸을까? === -다른 버전 관리 시스템들과 같이 Git은 누군가를 탓할 수 있는 기능이 있습니다: +다른 VCS들과 같이 Git은 누군가를 탓할 수 있는 기능이 있습니다: $ git blame bug.c -이 명령어를 사용하면 누가 언제 마지막으로 코딩작업을 했는지 표시하여 줍니다. 다른 버전 관리 시스템들과는 달리 모든 작업은 오프라인에서 진행됩니다. +이 명령어를 사용하면 누가 언제 마지막으로 어느 부분을 작업하였는지 표시하여 줍니다. 다른 VCS들과는 달리 모든 작업은 오프라인에서 진행됩니다. === 나의 개인경험담 === -중앙 버전 관리 시스템에서는 파일기록 변경은 어려울 뿐만아니라 -관리자만이 변경할 수 있습니다. 클론, 나뭇가지 만들기와 병합하기는 +중앙관리식 VCS에서는 파일들의 기록 변경은 어려울 뿐만아니라 +관리자만이 변경할 수 있습니다. 클론, branch 만들기와 병합하기는 네트워크를 통해서만 할 수 있는 작업들입니다. 브라우징 기록보기, commit하기 -역시 중앙 버전 관리 시스템에서는 네트워크를 통해야만 합니다. 어떤 시스템에서는 +역시 중앙관리식 VCS에서는 네트워크를 통해야만 합니다. 어떤 시스템에서는 네트워크 연결이 되어야지만 자기 자신이 작업한 기록을 보거나 편집할 수 있습니다. -중앙 버전 관리 시스템은 개발자의 수가 늘어남에 비례해서 더 많은 네트워크 통신을 -요구하기 때문에 오프라인에서 작업하는 것보다 비싸질 수 밖에 없습니다. 그리고 +중앙관리식 VCS는 개발자의 수가 늘어남에 비례해서 더 많은 네트워크 통신을 +요구하기 때문에 오프라인에서 작업하는 것보다 비경제적일 수 밖에 없습니다. 그리고 제일 중요한 것은 모든 개발자들이 고급명령어들을 적재적소에 쓰지 않는다면 -모든 작업이 어느정도는 무조건 느릴 수 밖에 없다는 것입니다. 극적인 케이스에서는 -아주 기본적인 명령어 만으로도 잘못하면 느려질 수 밖에 없습니다. 무거운 -명령어를 써야하나면 일의 효율성은 나쁜영향을 받을 수 밖에 없습니다. - -저는 직접 이런 상황들을 겪어보았습니다. Git은 제가 사용한 버전 관리 시스템 중에 -제일 처음이었죠. 저는 Git의 여러기능들을 당연하다 생각하고 금방 적응하였습니다. -저는 당연히 다른 버전 관리 시스템들 역시 Git이 제공하는 기능들을 가지고 있을 것이라고 -생각하였습니다: 버전 관리 시스템을 선택하는 것은 텍스트 에디터나 웹 브라우저를 +모든 작업이 어느정도는 무조건 느릴 수 밖에 없다는 것입니다. 극적인 경우에는 +아주 기본적인 명령어 역시 잘못하면 느려질 수 밖에 없습니다. 무거운 +명령어를 써야한다면 일의 효율성은 나쁜영향을 받을 수 밖에 없습니다. + +저는 직접 이런 상황들을 겪어보았습니다. Git은 제가 사용한 가장 먼저 사용한 VCS였죠. 저는 Git의 여러기능들을 당연하다 생각하고 금방 적응하였습니다. +저는 당연히 다른 VCS들 역시 Git이 제공하는 기능들을 가지고 있을 것이라고 +생각하였습니다: VCS를 선택하는 것은 텍스트 에디터나 웹 브라우저를 선택하는 것과 같은 맥락일 것이라고 생각하였습니다. -제가 중앙 버전 관리 시스템을 처음 사용하게 되었을땐 완전 쇼킹이였죠. 불안정한 인터 연결은 +제가 나중에 강제로 중앙관리식 VCS를 사용하게 되었을땐 완전 쇼킹이였죠. 불안정한 인터넷연결은 Git을 사용할 때 중요치 않습니다. 그러나 이러한 인터넷연결은 로컬디스크에서 작업하는 것 -만큼은 절대 될 수 없죠. 그리고 저는 어떤 명령어는 연결 딜레이를 고려함에 따라 -쓰지 않게되는 걸 시간이 지나며 깨달았습니다. 이런 행동은 제가 정말 하고싶었던 -작업을 완벽히 이행하지 못하게 하는 방해물이 되었죠. +만큼은 효율적 일수는 없죠. 그리고 저는 어떤 명령어는 연결 딜레이를 고려함에 따라 +습관적으로 쓰지 않고있는 걸 시간이 지나며 깨달았습니다. 이런 습관은 제가 원하는 방식대로 작업을 할 수 없게하는 방해물들이었죠. 어쩔 수 없이 느린 명령어를 사용할 때는 저의 작업효율에 치명타를 입히기 -일쑤였죠. 네트워크 연결이 완료되길 기다리면서 이메일 확인 및 다른 문서작업을 하며 +일쑤였죠. 네트워크로 처리되야하는 작업이 완료되길 기다리면서 이메일 확인 및 다른 문서작업을 하며 시간을 때웠습니다. 그러다가 원래하던 작업에 돌아가면 다시 무엇을 했었는지 -기억을 해내는데 시간이 많이 허비된 경험이 허다했습니다. 인간은 환경변화에 -적응을 할 수는 있으나 빠르진 않죠. +기억을 해내는데 시간이 많이 허비된 경험이 잦았습니다. 인간은 환경변화에 +적응을 할 수는 있으나 그 적응이 결코 빠르진 않죠. -공유된는 비극도 존재했죠: 네트워크 상황이 원활하지 않을 것이라는 기대와 미래에 -네트워크 딜레이를 줄이기위해 기울인 노력들은 오히려 트래픽을 더 잡아먹을 수가 -있다는 것입니다. 모든 개발자들이 네트워크를 원활하게하는 노력을 할수록 오히려 -해가 될 수있다는 것입니다. 이게 무슨 아이러니한 일입니까? \ No newline at end of file +일을 하면서 발생하는 아이러니한 비극도 존재했죠: 네트워크 상황이 원활하지 않을 것이라는 걸 아는 개발자들은 미래에 딜레이를 줄이기위해 지금 하는 작업들이 오히려 현재 트래픽을 더 잡아먹을 수가 +있다는 것입니다. 모든 개발자들이 네트워크를 원활하게하는 노력을 할수록 오히려 서로에게 해가 될 수있다는 것입니다. 이게 무슨 아이러니한 일입니까? \ No newline at end of file diff --git a/ko/intro.txt b/ko/intro.txt index d60f71fe..88512c90 100644 --- a/ko/intro.txt +++ b/ko/intro.txt @@ -1,59 +1,59 @@ == 도입부 == -저는 비유법을 사용하여 버전 관리 시스템에 대하여 설명해보려 합니다. http://en.wikipedia.org/wiki/Revision_control 를 방문하셔서 덜 정신나간 버전의 설명을 보시길 권장합니다. +Github에 대해 설명하기 쉽게 비유법을 사용하여 버전 관리 시스템 (Version Control System; 이하 VCS)를 설명해보려 합니다. 제가 하려는 설명에 비해 덜 정신나간 버전의 설명을 원하시면 http://en.wikipedia.org/wiki/Revision_control 를 방문하시길 권장합니다. -=== 일하는 것은 곧 노는 것 === +=== "일하는 것"은 곧 "노는 것" === -저는 거의 평생을 컴퓨터게임을 하며 지냈습니다. 하지만 어른이 되서야 버전 관리 시스템을 사용하기 시작했지요. 이런 건 저 혼자가 아닐 것이라 생각합니다. 그럼으로써 Git을 게임에 비유하며 설명하는 것이 Git을 이해하는 데 도움이 될 것이라 생각합니다. +저는 거의 평생을 컴퓨터게임을 하며 지냈습니다. 그에 반해, 어른이 되서야 VCS를 사용하기 시작했지요. 이런 건 저 혼자가 아닐 것이라 생각하니, Git을 게임에 비유하며 설명하는 것이 Git을 이해하는 데 도움이 될 것이라 생각합니다. -코드나 문서를 편집하는 작업이 게임을 하는 것과 같다고 생각해보세요. 편집을 마친 후에는 세이브하고 싶겠지요. 그렇게 하기 위해서는 당신의 믿음직한 에디터에서 '세이브' 버튼을 누르면 될 것입니다. +자, 이제 코드나 문서를 편집하는 작업이 게임을 하는 것과 같다고 생각해보세요. 편집을 마친 후에는 세이브하고 싶겠지요? 그렇게 하기 위해서는 당신의 든든한 코딩에디터에서 '세이브' 버튼을 누르면 될 것입니다. -그러나 이러한 행동은 예전 세이브를 덮어쓰는 결과를 초래하죠. 세이브 슬롯이 한 개밖에 없는 옛날 구형 게임을 생각하면 됩니다. 다시 말하자면, 세이브를 할 수는 있지만, 당신은 예전 세이브포인트로 돌아갈 수 없는 것 입니다. 이건 참...게임을 아주 재미있는 순간에 세이브를 해 놓았는데 돌아갈 수 없다는 것이죠. 더 나쁜 상황으로는, 당신의 세이브는 더 이상 이길 수없는 상태에 되어 있을 수도 있습니다. 그럴 경우에는 아주 처음부터 다시 시작해야 되겠지요. +그러나 단순히 '세이브'를 누르는 것은 예전 세이브를 덮어쓰는 결과를 초래하죠. 세이브 슬롯이 한 개밖에 없는 옛날 구형 게임을 생각하면 됩니다. 다시 말하자면, 세이브를 할 수는 있지만, 예전 세이브포인트로 돌아갈 수 없는 것 입니다. 마치, 게임 진행하다가 정말 재미있는 파트에 적재적소에 맞게 세이브를 해 놓았는데 그 포인트로 다신 돌아갈 수 없다는 것이죠. 좀 더 심하게 말하자면, 절대로 깰 수 없는 보스 앞에서 세이브를 한 당신은 그 상태에 평생 머무르게 될수도 있다는 것 입니다. 그럴 경우에는 아주 처음부터 다시 시작해야 된다는 말이 되겠지요. === 버전 관리 === -편집 시, '다른 이름으로 저장' 기능 및 사본을 다른 디렉토리에 만들어 놓는 방법 등을 이용해 오래된 버전을 보존할 수는 있습니다. 용량을 효율적으로 사용하기 위해서 압축을 할 수도 있죠. 이것은 참 원시적인 버전 컨트롤 방법입니다. 컴퓨터게임은 이런 과정에서 발전해 나간지 오래되었지요. 요즘 게임들은 여러개의 세이브 슬롯을 잘 활용하고 있습니다. +코드 등을 편집 시, '다른 이름으로 저장' 아니면 사본을 다른 디렉토리에 카피 떠 놓는 방법 등을 이용해 옛 버전의 코드들을 보존할 수는 있습니다. 컴퓨터 용량을 더욱 효율적으로 사용하기 위해서 압축을 할 수도 있죠. 이것은 참 원시적인 버전 컨트롤 방법입니다. 컴퓨터게임은 이런 과정에서 이미 발전해 나간지 오래되었지요. 요즘 게임들은 여러개의 세이브 슬롯에 시간을 기록해가며 세이브를 영리하게 해냅니다. -이 문제를 좀 더 꼬아서 보죠. 어떤 프로젝트나 웹사이트를 구성하는 소스코드와 같이 여러개의 파일이 하나로 묶여있다고 가정합시다. 현 버전의 프로젝트/웹사이트를 세이브하고 싶다면 모든 디렉토리를 기록해야 한다는 번거로움이 있지요. 일일이 많은 버전들을 관리한다는 것은 그리 효율적이지 않을 겁니다. +이 문제를 좀 더 꼬아서 바라봅시다. 당신이 어떤 프로젝트나 웹사이트를 구성하는 소스코드와 같이 여러개의 파일을 보유한다고 가정합시다. 현 버전의 프로젝트/웹사이트를 세이브하고 싶다면 모든 디렉토리를 기록해야 한다는 번거로움이 있겠지요. 일일이 그 수 많은 버전들을 수동으로 관리한다는 것은 그리 효율적이지 않을 겁니다. 컴퓨터 용량도 더불어 많이 사용하게 될꺼고요. 어떤 컴퓨터게임들은 정말로 모든 디렉토리를 각개 관리하는 형식으로 게임을 세이브하기도 합니다. 이런 게임들은 이런 불필요하게 세부적인 사항들을 게이머들이 보지 못 하게 하고 간편한 인터페이스를 통해 게이머들이 세이브파일들을 관리할 수 있게 해둡니다. -버전 관리 시스템은 이런 컨셉과 그리 다르지 않습니다. 버전 관리 시스템들은 디렉토리 등을 관리하기에 편한 인터페이스로 구성되어 있습니다. 원하는 만큼 세이브 및 불러오기를 실행할 수 있습니다. 컴퓨터게임들과는 다르게 용량을 효율적으로 사용하는 데에는 탁월한 성능을 보여주죠. 대부분의 케이스는 소수의 파일들만 살짝 편집을 하게되죠. 디렉토리 전체를 세이브하는 것 보다는 버전과 버전사이의 차이를 세이브하는 것이 용량을 효율적으로 쓰는 버전 컨트롤의 비밀입니다. +VCS는 이런 컨셉과 그리 다르지 않습니다. VCS들은 파일 디렉토리들을 관리하기에 아주 편한 인터페이스로 구성되어 있습니다. 원하는 횟수 만큼 세이브를 할 수 있고, 원하는 세이브포인트를 특정지어 불러오기를 실행할 수도 있습니다. 그리고 컴퓨터게임들과는 다르게 용량을 효율적으로 사용하는 데에는 탁월한 성능을 보여주죠. 대부분의 어떤 코드의 버전을 바꿀 때에는 소수의 파일들만 살짝 바꾸게되죠. 코드자체가 아주 많이 바뀌는 경우는 드뭅니다. 디렉토리 전체를 세이브하는 것 보다는 버전과 버전사이의 차이를 세이브하는 것이 용량을 효율적으로 쓰는 VCS의 비밀입니다. === 분산 제어 === -어려운 컴퓨터 게임을 한다고 생각해보세요. 너무 어렵기 때문에 전 세계의 프로게이머들이 팀을 구성해 이 게임을 끝내보겠다고 합니다. 게임을 빨리 끝내는 것에 초점을 두는 스피드런이 현실적인 예 이지요: 각기 다른 특기를 가지고 있는 게이머들이 각자 자신있는 부분에서 활약함으로써 성공적인 결과를 만들어내는 것을 예로 들어봅니다. +여러분이 어려운 컴퓨터 게임을 한다고 생각해보세요. 너무 어렵기 때문에 전 세계의 프로게이머들이 팀을 구성해 이 게임을 끝내보겠다고 합니다. 게임을 빨리 끝내는 것에 초점을 두는 스피드런 방식의 게임 스타일이 현실적인 예시 이지요: 각기 다른 특기를 가지고 있는 게이머들이 한 게임 안에서 각자 자신있는 부분을 담당함으로써 성공적인 결과를 만들어내는 것을 예로 들어봅니다. -어떻게 시스템을 구축해 두어야 게이머들이 서로의 세이브파일들을 올리거나 이어 받을 수 있을까요? +어떻게 시스템을 구축해 두어야 게이머들이 서로의 세이브파일들을 쉽게 업로드 하거나, 바통을 이어 받을 수 있을까요? -예전에 게임들은 중앙 집중식 버전 관리 시스템을 사용하였습니다. 한 개의 서버가 모든 게임 세이브파일을 저장했었지요. 그 서버외에는 아무 것도 그 세이브파일들을 관리할 수 있지 않았습니다. 풀어 말하면, 게이머들은 각자의 컴퓨터에 몇 개의 세이브파일들을 가지고 있었고, 게임을 진행하고 싶을 때에는, 파일들이 저장되어있는 서버에서 다운로드 받은 후, 게임을 좀 하다가, 다시 다른 게이머들이 진행할 수 있게 그 서버에 업로드 해 놓아야 합니다. +프로그래밍 프로젝트들은 예전에 중앙 집중식 VCS를 사용하였습니다. 한 개의 서버가 모든 세이브파일을 저장했었지요. 그 서버외에는 아무 것도 그 세이브파일들을 관리할 수 없었습니다. 게임으로 말하자면, 게이머들은 각자의 게임기에 몇 개의 세이브파일들을 가지고 있었고, 게임을 다른 사람으로부터 이어받아 진행하고 싶을 때에는, 모든 세이브파일들이 저장되어있는 중앙서버에서 파일들을 다운로드 받은 후, 게임을 좀 하다가, 다시 다른 게이머들이 진행할 수 있게 그 서버에 업로드 해 놓아야 합니다. -만약에 어떠한 이유에서라도 한 게이머가 예전에 세이브 해두었던 파일을 불러오고 싶다면 어떻게 될까요? 현재 세이브 시점은 아무리 잘 해도 이길 수 없는 상태로 저장이 되어있을지도 모르고, 게이머들은 현 시점보다 전으로 돌아가서 아까 못 구했던 강력한 아이템을 얻을 수 있는 시점으로 돌아가고 싶을지도 모릅니다. 그런게 아니라면 그들은 아마도 세이브파일 두 개를 비교하여 한 특정 게이머가 얼마나 진행을 해두었는지 알고 싶어할지도 모릅니다. +만약에 어떤 한 게이머가 예전에 세이브 해두었던 오래된 파일을 불러오고 싶다면 어떻게 될까요? 현재 최신의 세이브 시점은 누군가 게임의 전 단계에서 다음 단계에 필요한 아이템을 주워오지 않아서 아무리 잘 해도 게임을 진행 할수없는 상태로 저장이 되어있을지도 모르고, 그런게 아니라면 그들은 아마도 세이브파일 두 개를 비교하여 한 특정 게이머가 얼마나 진행을 하였는지 알고 싶어할지도 모릅니다. 예전 세이브 파일을 불러오고 싶은 이유는 여러가지일 수 있습니다, 그러나 방법은 한 가지일 수 밖에 없지요. 중앙서버에서 불러오는 방법 말입니다. 더 많은 세이브파일을 원할 수록 서버와의 통신이 더 잦아질 수 밖에 없지요. -새로운 세대의 버전 관리 시스템들은 (Git을 포함하여), 분산 제어를 기본으로 합니다. 예전의 중앙관리 방식의 보편화된 방식이라고 생각하면 되지요. 한 게이머가 서버로부터 세이브파일을 받는다면 하나만 받게되는 것이 아니라 모든 세이브파일 받게 되는 겁니다. 중앙서버를 각자의 컴퓨터에 미러링한다고 보시면 됩니다. +(Git을 포함하여) 새로운 세대의 VCS들은 분산 제어를 기본으로 합니다. 예전의 중앙관리 방식의 보편화된 방식이라고 생각하면 되지요. 한 게이머가 서버로부터 (가장 최신) 세이브파일을 받는다해도 그 하나만 받게되는 것이 아니라 모든 예전 버전의 세이브파일까지도 같이 받게 되는 겁니다. 마치 중앙서버를 각자의 컴퓨터에 미러링한다고 보시면 됩니다. -처음에는 시간이 많이 걸릴 수 있습니다. 특히 그 세이브파일이 아주 긴 역사를 가지고 있다면 말이지요. 그러나 이 것은 길게보면 아주 효율적인 방법입니다. 이 방법을 통해 즉시 이득을 볼 수있는 점을 따진다면, 예전 세이브파일을 원할 때 중앙서버와 교신을 하지 않아도 된다는 점이지요. +그렇기에 처음에는 Git을 셋업할 때 시간이 많이 걸릴 수 있습니다. 특히, 그 세이브파일이 오래되었고, 아주 긴 역사를 가지고 있다면 말이지요. 그러나 이 것은 길게보면 아주 효율적인 방법입니다. 이 방법을 통해 즉시 이득을 볼 수있는 점을 따진다면, 예전 세이브파일을 원할 때 중앙서버와 교신을 하지 않아도 된다는 점이지요. === 멍청한 미신 === -분산 제어 시스템에 대한 보편적인 오해가 있다면, 이 시스템은 공식적인 중앙 저장소가 필요한 프로젝트에는 적합하지 않다고 생각하는 것입니다. 이 것은 말도 안되는 오해이지요. 이 오해는 누군가의 사진을 찍는다는 것은 그 피사체의 영혼을 빨아온다는 말도 안 되는 논리와 같습니다. 다시 말하면, 중앙 저장소의 파일을 사본하는 것이 중앙 저장소의 중요성을 훼손한다는 것이 아닙니다. +사람들이 분산 제어 시스템에 대해 일반적으로 오해하는게, 분산 제어 시스템은 공식적인 중앙 저장소가 필요한 프로젝트에는 적합하지 않다고 생각하는 것입니다. 이 것은 말도 안되는 오해이지요. 이 오해는 누군가의 사진을 찍는다는 것은 그 피사체의 영혼을 같이 담아버린다는 말도 안 되는 논리와 같습니다. 다시 말하면, 중앙 저장소의 파일을 카피하여 분산 제어하는 것이 중앙 저장소의 중요성을 훼손한다는 것이 아닙니다. -중앙 버전 관리 시스템이 할 수 있는 모든 일들은 잘 짜여진 분산 관리 시스템이 더 잘 할수 있다는 것을 알아야 합니다. 네트워크상의 자원들은 기본적으로 로컬상의 자원들보다 비경제적일 수 밖에 없습니다. 나중에도 말씀드리겠지만 분산 제어 시스템도 문제점이 없는 시스템은 아닙니다. 그러나 주먹구구식의 생각으로 중앙 관리 시스템과 분산 관리 시스템을 비교하는 일은 없어야 할 것입니다. 다음 인용문이 이 것을 대변해 줍니다. +첫번째 이해해야하는 부분이, 중앙 버전 관리 시스템이 할 수 있는 모든 일들은 잘 짜여진 분산 관리 시스템이 더 잘 할수 있다는 것을 인식해야 한다는 것입니다. 네트워크상의 자원들은 기본적으로 로컬상의 자원들보다 시간적으로나 물질적으로 비경제적일 수 밖에 없습니다. 물론, 나중에도 말씀드리겠지만 분산 제어 시스템도 문제점이 없는 시스템은 아닙니다. 그러나 주먹구구식의 생각으로 중앙 관리 시스템과 분산 관리 시스템을 비교하는 일은 없어야 할 것입니다. 다음 인용문이 이것을 대변해 줍니다. -규모가 작은 프로젝트는 어떤 시스템으로부터 부분적인 특성만이 필요할 지 모르지만, -규모가 작은 프로젝트를 잘못 스케일링하는 시스템은 마치 -로마 숫자를 이용해 작은 숫자들의 계산을 실행하는 것과 같다. +"규모가 작은 프로젝트들은 시스템의 부분적인 특성만으로도 실행 할 수 있겠지만, +이런 프로젝트들을 스케일업 할 수 없는 확장성이 낮은 시스템으로 계속 실행하는 것은 마치 +옛 로마숫자를 이용해 계산기를 두드리는 것과 같다." -더욱이 당신의 프로젝트는 당신이 생각했던 것보다 더 큰 일이 될지도 모릅니다. 처음부터 Git을 사용한다는 것은 아무리 병뚜껑을 여는 데만 쓴다하여도 스위스아미나이프를 들고 다니는 것과 같은 것입니다. 드라이버가 필요할 경우 당신은 병따개를 들고다니지 않았다는 사실에 안도의 한 숨을 쉴 수 있을 것 입니다. +더욱이 당신의 프로젝트는 당신이 처음 생각했던 것보다 더 거대한 일이 될지도 모르는 겁니다. 처음부터 Git을 사용한다는 것은 단순히 병뚜껑을 여는데 스위스아미나이프를 들고 다니는 것과 같은 것입니다. 그러나, 어느 날, 드라이버가 필요할 경우, 당신은 병따개만 들고다니지 않았다는 사실에 안도의 한 숨을 쉬게 될 것입니다. -=== 결합의 오류 === +=== 병합 충돌 === -이 주제를 설명하기 위해서는 컴퓨터 게임에 비유하는 것은 더 이상 적합하지 않을 수 있습니다. 대신에 여기서는 문서편집에 비유해서 설명드리도록 하죠. +이 주제를 설명하기 위해서는 컴퓨터게임에 비유하는 것은 더 이상 적합하지 않을 수 있습니다. 대신에 여기서는 문서편집에 비유해서 설명드리도록 하죠. -앨리스는 파일 편집 중 첫 줄에 새로운 줄을 추가하고, 밥은 그 파일의 마지막에 한 줄을 넣는다고 가정합니다. 그들은 편집된 파일을 업로드 합니다. 대부분의 시스템은 자동으로 두 사람이 한 편집을 받아들이고 병합할 것입니다. 결과적으로는 앨리스와 밥 두 사람의 편집이 적용될 것입니다. +다음 예시를 생각해 봅시다. 앨리스(Alice)는 파일을 편집하던 도중에 새로운 줄을 첫 줄로 추가하고, 밥(Bob)은 그 같은 파일의 마지막에 코드 한 줄을 더한다고 가정합시다. 그리고 그들은 편집된 파일을 각자 중앙서버에 업로드 합니다. 대부분의 시스템은 자동으로 두 사람이 각자 한 편집을 받아들이고 병합할 것입니다. 결과적으로는 앨리스와 밥 두 사람의 편집이 모두 한 파일에 적용되겠죠. -자 이제 앨리스와 밥이 같은 부분에서 서로 다른 편집을 한다고 가정해 봅니다. 인간의 직접적인 개입없이는 불가능 하겠지요. 누가 편집을하던 두번째로 편집하는 사람은 merge conflict라는 메세지를 볼 수밖에 없겠지요. 한 사람만의 편집을 선택하거나 두 사람의 편집과는 다른 세번째 편집을 생각해 봐야 할 겁니다. +자 이제 앨리스와 밥이 어떤 파일의 정확히 같은 부분에서 서로 다른 편집을 한다고 가정해 봅시다. 이럴 경우에는 인간의 직접적인 개입없이는 온순한 편집이 불가능 하겠지요? 누가 편집을하던 두번째로 편집하는 사람은 작업을 결합하는 과정에서 오류메세지 ("_merge conflict_")를 볼 수밖에 없겠지요. 이런 오류메세지를 피하기 위해선 한 사람만의 작업을 선택하거나 두 사람의 작업을 아우를 수 있는 새로운 코딩작업을 추가로 해줘야하는 번거로움이 발생하지요. -더 복잡한 상황이 일어날 수 있습니다. 버전 관리 시스템은 간단한 상황들을 알아서 해결해 줍니다. 어려운 상황은 인간의 손에 맡기지요. 시스템의 행동은 대체적으로 조정가능합니다. +예시보다 더 복잡한 상황이 일어날수도 있습니다. VCS는 간단한 상황들을 알아서 해결해 주고, 어려운 상황은 인간의 손에 맡기지요. 이런 VCS의 행동은 대체적으로 조정가능합니다. diff --git a/ko/multiplayer.txt b/ko/multiplayer.txt index 11aab3c5..7428c6ad 100644 --- a/ko/multiplayer.txt +++ b/ko/multiplayer.txt @@ -1,7 +1,7 @@ == Git은 멀티플레이어 == -제가 과거 프리랜서 시절부터 Git을 개인적인 용도로 사용해 오고있었습니다. -여태까지 소개했던 많은 명령어들 중, 당시에는 *pull*과 *clone정도만 사용하여 +제가 과거에 단독 개발자였던 시절부터 Git을 사용해 오고있었습니다. +그 당시엔 여태까지 소개했던 많은 명령어들 중 *pull*과 *clone*정도만 사용하여 같은 프로젝트를 여러 디렉토리에 저장하는데 사용하였습니다. 시간이 지난 후 Git에 제가 만든 코드를 올리고 싶었고 다른 개발자들이 @@ -11,22 +11,22 @@ Git이 존재하는 이유이기도 하지요. === 난 누굴까? === -각 commit은 작성자의 이름과 작성자의 이메일주소를 저장합니다. *git log*를 사용해 조회할 수 있습니다. -기본설정 상, Git은 시스템 세팅을 이용해 작성자의 이름과 이메일주소를 저장합니다. -수동으로 이름과 이메일주소를 설정하려면: +각 commit은 작성자의 이름과 작성자의 이메일주소를 저장합니다. 이 목록은 *git log*를 사용해 조회할 수 있습니다. +기본설정 상 Git은 시스템에 이미 기본으로 세팅이 되어있는 정보를 이용해 작성자의 이름과 이메일주소를 저장합니다. +그러나 수동으로 이름과 이메일주소를 설정하려면: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -현재 사용중인 저장소에만 사용할 수 있는 작성자 이름이나 이메일을 설정하려면 위 명령어는 -사용하지마세요. +를 사용하여 지정해 주십시오. + +현재 사용중인 repository에만 한정적으로 사용할 수 있는 이름이나 이메일을 설정하려면 위 명령어에서 *--global*을 사용하지마세요. -=== Git 을 통한 SSH, HTTP 연결 === +=== SSH, HTTP를 통한 Git 사용 === -웹 서버에 관한 SSH 접근권한을 보유하고 있다고 합니다. Git은 아직 설치되어 있지않다고 가정합니다. -기존 프로토콜만큼 효율적이진 않겠지만, Git은 HTTP를 통해 데이터 교환이 가능합니다. +웹 서버에 관한 SSH 접근권한을 보유하고 있다고 합니다. 그러나 Git은 아직 설치되어 있지않다고 가정합니다. 기존 프로토콜만큼 효율적이진 않겠지만, Git은 HTTP를 통해 데이터 교환이 가능합니다. -Git을 다운받아서 설치합니다. 그리고 웹 디렉토리에 저장소를 만듭니다: +우선 기본적으로 컴퓨터에 Git을 다운받아서 설치합니다. 그리고 웹 디렉토리에 저장소를 만듭니다: $ GIT_DIR=proj.git git init $ cd proj.git @@ -47,35 +47,30 @@ Git의 예전 버전에선 복사를 지시하는 명령어가 안 들을 수 === 모든 것은 Git을 통한다 === -서버와의 연결없이 저장소를 동기화시키고 싶다고요? +서버나 인터넷 연결없이 저장소를 동기화시키고 싶다고요? 긴급하게 수정할 것이 발견되었다고요? <>. -여러가지 매개체를 통해서 저장소의 파일들을 옮길 수 있지만, 정말 효율적인 +fast-export* 그리고 *git fast-import* 명령어들은 repository를 하나의 파일로 +묶어주거나 그 하나의 파일을 repository로 되돌려 줄 수 있는 것을 배웠습니다>>. +다양한 매개체를 통해서 repository의 파일들을 옮길 수 있지만, 정말 효율적인 방법은 *git bundle* 명령어를 쓰는 것입니다. 보내는 이가 '묶음 (bundle)'을 만듭니다: $ git bundle create somefile HEAD - 그리고 다른 장소로 그 묶음, +somefile+을 어떻게든 옮겨야합니다: 이메일, USB드라이브, - *xxd* 프린트, OCR 스캐너, 전화로 이야기하던지, 연기로 신호를 보내던지 등 어떻게든 - 보내야합니다. 파일을 받을 사람들은 이 묶음으로부터의 commit을 다음 명령어를 이용하여 - 받을 수 있습니다: + 그리고 다른 장소로 그 묶음, +somefile+을 어떻게든 옮겨야한다고 가정합시다: 이메일로 보내야할수도 있고, USB드라이브로 보내거나, *xxd* 프린트로 뽑아서 전송하던지, OCR 스캐너로 전송하던지, 전화로 직접 이야기하던지, 연기로 신호를 보내던지 등 어떻게든 보내야합니다. 파일을 받을 사람들은 이 묶음으로부터의 commit을 다음 명령어를 이용하여 간단히 받을 수 있습니다: $ git pull somefile - 파일을 받는 사람들은 빈 저장소에서도 이 명령어를 사용할 수 있습니다. 파일의 - 사이즈에도 불구하고 +somefile+ 은 저장소의 본 모습을 담고 있습니다. + 파일을 받는 사람들은 빈 repository에서도 이 명령어를 사용할 수 있습니다. 파일의 + 사이즈가 작아 보임에도 불구하고 +somefile+ 은 저장소의 본 모습을 담고 있습니다. 큰 프로젝트에서는 묶음만들기를 좀 더 효율적으로 하기위해서 버전차이만을 -묶어줍니다. 예를 들어서 "1b6d"를 commit 이 가장 최근에 공유된 commit이라고 -가정해 봅니다: +묶어줍니다. 예를 들어서 "1b6d"의 hash가 달린 commit 이 가장 최근에 보내는 이와 받는 이 사이에 공유된 commit이라고 가정해 봅니다: $ git bundle create somefile HEAD ^1b6d -너무 자주 이렇게 한다면, 어떤 commit이 가장 최근 것인지 기억하지 못할 수 있습니다. 도움말에서는 -태그를 이용해 이런 문제점들을 피하라 명시합니다. 다시 말하자면 어떤 묶음을 보낸 후에는: +너무 자주 이렇게 한다면, 어떤 commit이 가장 최근 것인지 기억하지 못할 수 있습니다. 도움말에서는 태그를 이용해 이런 문제점들을 피하라 명시합니다. 풀어서 말하자면 어떤 묶음을 보낸 후에는: $ git tag -f lastbundle HEAD @@ -86,23 +81,22 @@ fast-export* 그리고 *git fast-import* 명령어들은 저장소를 하나의 === 패치: 세계적 통화 === 패치는 컴퓨터와 인간이 쉽게 알아들을 수 있는 언어로 파일의 변화를 -텍스트로 표현할 수 있는 방법입니다. 이런 식으로 세계적으로 다양하게 사용되고 있습니다. -어떠한 버전 관리 시스템을 쓰던간에 개발자들에게 패치를 이메일로 보낼 수 있습니다. 그 개발자들이 -그 이메일을 읽을 수만 있다면 그들은 당신이 편집을 한 작업기록을 볼 수 있습니다. +텍스트로 표현할 수 있는 방법입니다. 전 세계 어떤 개발 공간에서나 이런 식으로 파일의 변화를 시도합니다. +어떠한 VCS를 쓰던간에 개발자들에게 패치를 이메일로 보낼 수도 있습니다. 그 개발자들이 +그 이메일을 읽을 수만 있다면 그들은 당신이 편집을 한 작업기록을 손쉽게 볼 수 있을겁니다. 즉, 온라인용 Git repository를 만들 필요가 없다는 말이지요. 첫 장에서 본 명령어를 다시 한번 해봅시다: $ git diff 1b6d > my.patch -위 명령어는 이메일로 추후에 토론할 수 있게 패치를 붙여넣기 하여 공유할 수동으로 -있었습니다. Git 저장소에서 다음을 따라해보세요: +위 명령어는 간단한 패치를 생성하여 이메일로 보낼수 있게 도와줍니다. Git 저장소에서 다음을 따라해보세요: $ git apply < my.patch 위 명령어를 사용하여 패치를 적용시킵니다. 작성자의 이름과 싸인이 기록되어야하는 좀 더 공식적인 환경에서는 -그에 상응하는 패치 (commit 1b6d 이후)를 만들기위해 다음 명령어를 사용합니다: +그에 상응하는 패치 (1b6d 이후의 작업)를 만들기위해 다음 명령어를 사용합니다: $ git format-patch 1b6d @@ -110,13 +104,13 @@ fast-export* 그리고 *git fast-import* 명령어들은 저장소를 하나의 $ git format-patch 1b6d..HEAD^^ -받는 쪽에서는 이메일을 받을 때: +받는 쪽에서는 이메일을 받을 때는 받은 txt형태의 패치 파일을 저장한 후: $ git am < email.txt 이 명령어는 새로받은 패치를 적용시키고 작성자의 정보가 포함된 새로운 commit을 만듭니다. -패치를 받기전에, 당신의 이메일 클라이언트에서 이메일에 첨부된 commit 묶음이 어떤 사람에 의해 포맷이 바뀌진 않았는지 확인합니다. +브라우저 상으로 이메일을 수신한다면, 당신의 이메일 클라이언트에서 첨부된 패치의 본 코드의 형태를 확인해야 할수도 있습니다. mbox-를 기반으로하는 이메일 클라이언트는 약간의 문제점들이 있습니다. 그러나 이런 방식의 클라이언트를 쓸만한 사람이라면 손쉽게 튜토리얼을 읽지않고도 @@ -124,42 +118,39 @@ mbox-를 기반으로하는 이메일 클라이언트는 약간의 문제점들 === 죄송합니다. 주소를 옮겼습니다 === -저장소를 클로닝한 후 *git push*나 *git pull*을 사용하면 원래의 URL에서 해당 +Repository를 클로닝한 후 *git push*나 *git pull*을 사용하면 원래의 URL에서 해당 명령어를 실행합니다. Git은 어떤 원리로 이렇게 하는 것일까요? 그 비밀은 클론을 만들때 생선된 config 옵션에서 찾을 수 있습니다. 한번 볼까요?: $ git config --list -+remote.origin.url+ 옵션은 URL 소스를 통제합니다; "origin"은 원래 저장소에 -붙여진 별명이라고 보면됩니다. 나뭇가지에는 "master"라고 이름이 붙듯이 말이죠. 그말은 ++remote.origin.url+ 옵션은 URL 소스를 통제합니다; "origin"은 원래 repository에 +붙여진 별명이라고 보면됩니다. Branch에 "master"라고 이름이 붙듯이 말이죠. 그말은 이 이름을 바꾸거나 지울 수 있는데 할 필요는 없다는 것입니다. -제일 처음 사용하던 저장소가 옮겨지면, URL을 수정해 주어야 합니다: +제일 처음 사용하던 repository가 옮겨지면, URL을 수정해 주어야 합니다: $ git config remote.origin.url git://new.url/proj.git -+brach.master.merge+ 옵션은 *git pull*로 당겨올 수 있는 나뭇가지를 -설정하여 줍니다. 처음으로 클론을 생성하였을때, 그 클론의 나뭇가지는 -그 클론을 만들어온 저장소의 현재 사용중인 저장소와 같게 설정이 되어있습니다. 그렇기 때문에 현재 작업 헤드가 -다른 나뭇가지로 옮겨갔었다고 하더라도, 추후의 당겨오기는 본래의 나뭇가지를 따를 수 있게 해줄 것 입니다. ++brach.master.merge+ 옵션은 *git pull*로 당겨올 수 있는 branch를 +설정하여 줍니다. 처음으로 클론을 생성하였을때, 그 클론의 branch는 +그 클론을 만들어온 repository의 현재 사용중인 repository와 같게 설정이 되어있습니다. 그렇기 때문에 현재 작업 헤드가 다른 branch로 옮겨갔었다고 하더라도, 추후의 당겨오기는 본래의 branch를 따를 수 있게 해줄 것 입니다. -본 옵션은 처음에 +branch.master.remote+옵션에 기록되어 있는 클론에만 적용됩니다. +본 옵션은 처음에 +branch.master.remote+옵션에 기록되어 있는 클론의 대상 repository에만 적용됩니다. 다른 저장소에서 당겨오기를 실행한다면, 구체적으로 어떤 나뭇가지에서 당겨오길 원하는지 설정해주어야 합니다: $ git pull git://example.com/other.git master -이 것은 왜 전에 보여드렸던 밀기와 당겨오기 예제에 다른 argument가 붙지 않았었는지 +이 것은 왜 전에 보여드렸던 *push*와 *pull* 예제에 다른 argument가 붙지 않았었는지 설명하여 줍니다. -=== 원격 나뭇가지 === +=== 원격 branch들 === -어떠한 저장소를 클론할 때에는 그 클론의 모든 나뭇가지를 클론하게 됩니다. Git은 이 사실을 은폐하기에 -당신은 클론을 하면서 몰랐을지도 모릅니다: 그러니 당신은 직접 Git에게 물어보아야 합니다. 이 설정은 원격 -저장소에 있는 나뭇가지들은 당신의 나뭇가지들을 꼬이게하는 일을 없게 해줍니다. 그래서 Git 역시 -초보자들이 사용할 수 있는 것이고요. +어떠한 repository를 클론할 때에는 그 클론의 모든 branch를 클론하게 됩니다. Git은 이 사실을 은폐하기에 +당신은 클론을 하면서 몰랐을지도 모릅니다: 그러니 당신은 직접 Git에게 물어보아야 합니다. 이 설정은 원격 repository에 있는 branch들은 당신의 branch들과 꼬이게하는 일을 없게 해줍니다. 그래서 초보자들이 Git을 사용할 수 있는 것이고요. -다음 명령어를 이용하여 원격 나뭇가지들을 나열합니다: +다음 명령어를 이용하여 숨겨진 branch들을 포함해서 모두 나열합니다: $ git branch -r @@ -169,10 +160,8 @@ mbox-를 기반으로하는 이메일 클라이언트는 약간의 문제점들 origin/master origin/experimental -이 결과는 각 행마다 원격저장소의 나뭇가지와 현 작업위치를 돌려주는 결과이며, 다른 Git 명령어들과 -함께 사용될 수 있습니다. 예를 들면, 당신은 지금 많은 commit을 하였다고 먼저 가정합니다. 그러고는 -가장 최근에 가져온 버젼과 비교를 하고싶다고 생각해봅니다. SHA1 해쉬를 찾아서 확인할 수도 있지만 -다음 명령어로 더 간단히 비교할 수 있습니다: +이 결과는 각 행마다 원격 repository의 HEAD와 branch를 보여주며, 다른 Git 명령어들과 +함께 사용될 수 있습니다. 예를 들면, 당신은 지금 많은 commit을 하였다고 먼저 가정합니다. 그러고는 가장 최근에 가져온 버젼과 비교를 하고싶다고 생각해봅니다. SHA1 해쉬를 찾아서 확인할 수도 있지만 다음 명령어로 더 간단히 비교할 수 있습니다: $ git diff origin/HEAD @@ -180,50 +169,49 @@ mbox-를 기반으로하는 이메일 클라이언트는 약간의 문제점들 $ git log origin/experimental -=== 다수의 원격저장소 === +=== 다수의 원격 repository === 당신 외의 두명의 개발자가 프로젝트를 공동으로 진행하고 있다고 가정합니다. 그리고 그 둘의 -작업상황을 주시하고 싶습니다. 당신은 다음 명령어를 사용함으로써 하나 이상의 저장소를 +작업상황을 주시하고 싶습니다. 당신은 다음 명령어를 사용함으로써 하나 이상의 repository를 추적할 수 있습니다: $ git remote add other git://example.com/some_repo.git $ git pull other some_branch -이제 두번째 저장소의 나뭇가지로 병합을 시도하였으며 모든 저장소의 모든 나뭇가지에 +이제 두번째 repository의 branch로 병합을 시도하였으며 모든 repository의 모든 branch에 대한 접근권한이 생겼습니다. $ git diff origin/experimental^ other/some_branch~5 그러나 내 작업과 관련없이 버전의 변화를 비교해내는 방법은 무엇일까요? 풀어말하자면 -그들의 나뭇가지를 보는 동시에 내 작업이 영향받지않게 하고싶다는 것입니다. 그렇다면 -당겨오기 보다는: +그들의 branch를 보는 동시에 그들의 작업이 내 작업에 영향받지않게 하고싶다는 것입니다. 그렇다면 +간단하게 당겨오기 보다는: - $ git fetch # 원래의 저장소로부터 물어옵니다. 디폴트 명령어. - $ git fetch other # 다른 개발자의 저장소를 물어옵니다. + $ git fetch # 태초의 repository로부터 물어옵니다. 디폴트 명령어. + $ git fetch other # 다른 개발자의 repository를 물어옵니다. -버전기록들만을 가져오는 명령어들입니다. 현재 작업중인 디렉토리는 영향을 받지않을 것이지만, 로컬 사본을 -가지고 있기에 우리는 이제 어느 저장소의 어떤 나뭇가지라도 Git 명령어를 사용하여 활용할 수 있습니다. +작업기록들만을 가져오는 명령어들입니다. 현재 작업중인 디렉토리는 영향을 받지않을 것이지만, 로컬 사본을 +가지고 있기에 우리는 이제 어느 repository의 어떤 branch라도 Git 명령어를 사용하여 활용할 수 있습니다. Pull은 간단히 풀어서 설명하면 *fetch(물어오기)* 후 *merge(병합하기)*를 합친 하나의 고급명령어라고 말할 수 있습니다. 우리는 마지막 으로 한 commit을 현재 작업에 병합하길 원하기 때문에 주로 *pull(당겨오기)*를 사용하게 될 것입니다; 위에 설명한 상황은 특수상황이지요. -*git help remote*에는 원격 저장소를 삭제하는 방법, 특정 나뭇가지를 무시하는 방법 외에 +*git help remote*에는 원격 repository를 삭제하는 방법, 특정 branch를 무시하는 방법 외에 많은 것을 볼 수 있습니다. === 나만의 취향 === -나는 작업을 할때 다른 개발자들이 내가 당겨오기를 실행할 수 있게 항시 준비해두는 것을 선호합니다. +저는 작업을 할때 다른 개발자들이 제가 당겨오기를 실행할 수 있게 항시 준비해두는 것을 선호합니다. 어떠한 Git 호스팅 서비스는 클릭 한 번만으로도 쉽게 이를 행할 수 있게 도와주는 것도 있습니다. 어떤 파일꾸러미를 물어온 후에는 Git 명령어들을 사용하여 프로젝트가 잘 정리되어 있길 빌며 -변화 기록을 조회합니다. 그러고는 나의 작업을 병합합니다. 그 후 내 작업이 맘에 들 경우 +변화 기록을 조회합니다. 그러고는 저의 작업을 병합합니다. 그 후 제 작업이 맘에 들 경우 메인 저장소에 밀어넣기 합니다. -다른 사람들로부터 많은 도움을 받는 스타일은 아니지만, 이러한 내 작업방식을 +제가 다른 사람들로부터 많은 도움을 받는 스타일은 아니지만, 이러한 제 작업방식을 추천드리고 싶습니다. 다음 링크를 한 번보세요. http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[Linus Torvalds의 블로그 포스팅]. -Git의 세상에 거주하는 것은 패치 파일들을 만들어 배포하는 것보다 더 효율적입니다. Git은 단순한 버전관리 외에도 -작업을 행한 사람의 이름, 이메일주소, 작업날짜를 같이 기록하여줍니다. \ No newline at end of file +Git의 세상에 거주하는 것은 패치 파일들을 만들어 배포하는 것보다 더 효율적입니다. Git은 단순한 버전관리 외에도 작업을 행한 사람의 이름, 이메일주소, 작업날짜를 같이 기록하여줍니다. \ No newline at end of file diff --git a/ko/preface.txt b/ko/preface.txt index 00fc212d..8c6fb207 100644 --- a/ko/preface.txt +++ b/ko/preface.txt @@ -4,19 +4,19 @@ Ben Lynn == 서문 == -http://git-scm.com/[Git] 은 버전 관리계의 스위스아미나이프 정도로 보면 됩니다. 아주 유연하고 믿을 수 있지만 그만큼 배우기는 어려울 수도있는 본 버전 관리 시스템을 마스터 해봅시다! +http://git-scm.com/[Git] 은 버전 관리계의 스위스아미나이프 정도로 보면 됩니다. 아주 유연하고 믿을 수 있지만 그만큼 배우기는 어려울 수도있는 이 Version Control System을 마스터 해봅시다! -Arthur C. Clarke는 충분히 발전한 기술은 마술과 같다고 말하였습니다. Git도 마찬가지입니다. 초보자들은 Git이 어떻게 돌아가는지 알 필요가 없으며 Git이라는 간단한 장치가 어떻게 친구들과 적들을 놀라게하는지만 알면됩니다. +Arthur C. Clarke는 충분히 발전한 기술은 마술과 같다고 말하였습니다. Git도 마찬가지입니다. 초보자들은 Git이 어떻게 돌아가는지 알 필요가 없으며 Git이라는 간단한 장치가 어떻게 친구들과 적들을 놀라게 하는지만 알면됩니다^^. 세부사항들을 설명하는 대신에, 우리는 몇몇 기능들의 대략적인 설명을 하려합니다. 여기에 설명된 기능들을 자주 사용하다 보면 각각의 명령어들이 어떻게 작동하는지 알게 될 것입니다. 그리고 그 명령어들을 적용하여 새로운 일들을 해낼 수 있겠지요. .번역판 - link:/\~blynn/gitmagic/intl/zh_cn/[Simplified Chinese]: by JunJie, Meng and JiangWei. Converted to link:/~blynn/gitmagic/intl/zh_tw/[Traditional Chinese] via +cconv -f UTF8-CN -t UTF8-TW+. - - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, and Nicolas Deram. Also hosted at http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, and Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[German]: by Benjamin Bellee and Armin Stebich; also http://gitmagic.lordofbikes.de/[hosted on Armin's website]. - link:/~blynn/gitmagic/intl/it/[Italian]: by Mattia Rigotti. - - link:/~blynn/gitmagic/intl/ko/[Korean]: by Jung-Ho (John) Han; also https://sites.google.com/site/drinkhanjohn/useful-links/[hosted on John's website]. + - link:/~blynn/gitmagic/intl/ko/ [Korean]: by John J. Han; also https://sites.google.com/site/drinkhanjohn/useful-links/[hosted on John's website]. - link:/~blynn/gitmagic/intl/pl/[Polish]: by Damian Michna. - link:/~blynn/gitmagic/intl/pt_br/[Brazilian Portuguese]: by José Inácio Serafini and Leonardo Siqueira Rodrigues. - link:/~blynn/gitmagic/intl/ru/[Russian]: by Tikhon Tarnavsky, Mikhail Dymskov, and others. diff --git a/ko/secrets.txt b/ko/secrets.txt index 4d0aa73d..3a7a85d0 100644 --- a/ko/secrets.txt +++ b/ko/secrets.txt @@ -1,131 +1,128 @@ -== Secrets Revealed == +== 비밀을 벗겨내다 == -We take a peek under the hood and explain how Git performs its miracles. I will skimp over details. For in-depth descriptions refer to http://schacon.github.com/git/user-manual.html[the user manual]. +Git의 안을 들여다보고 Git이 어떻게 작동하는지 알려드리겠습니다. 너무 디테일한 것들은 알아서 빼놓고 설명해드리겠습니다. +그래도 자세히 알고 싶은 분들은: http://schacon.github.com/git/user-manual.html[the user manual]로 가시길 바랍니다. -=== Invisibility === +=== 보이지 않는 능력 === -How can Git be so unobtrusive? Aside from occasional commits and merges, you can work as if you were unaware that version control exists. That is, until you need it, and that's when you're glad Git was watching over you the whole time. +Git은 어떻게 눈에 띄지않게 강력한 툴일 수 있을까요? 습관적으로 하게되는 commit과 병합을 제외하고, VCS자체가 컴퓨터에 설치되지 않은 것 같아보일 때가 있습니다. -Other version control systems force you to constantly struggle with red tape and bureaucracy. Permissions of files may be read-only unless you explicitly tell a central server which files you intend to edit. The most basic commands may slow to a crawl as the number of users increases. Work grinds to a halt when the network or the central server goes down. +다른 VCS들은 사용할때 쓸때없이 많은 절차와 검열 등으로 고생할 수 있습니다. 파일의 보안상태가 '읽기전용'으로 세팅되어 작업을 하려고 할 때마다 중앙서버에 승인을 요청해야 할 경우도 빈번합니다. +그리고 VCS의 유저들이 많아질수록 업무처리 속도가 현저히 떨어질수도 있습니다. 그리고 중앙서버나 네트워크가 다운 될 경우에는 아무런 작업을 할 수 없죠. -In contrast, Git simply keeps the history of your project in the `.git` directory in your working directory. This is your own copy of the history, so you can stay offline until you want to communicate with others. You have total control over the fate of your files because Git can easily recreate a saved state from `.git` at any time. +반면에, Git은 당신의 로컬컴퓨터 디렉토리에 '.git'디렉토리를 형성하여 그곳에 작업기록을 하게됩니다. 그 기록은 온전히 당신만의 것이죠. 그렇기에 오프라인 상태에서도 작업을 끊기지 않고 진행할 수 있습니다. +그리고 작업중인 파일에 대해 모든 권한을 가지고 있게 해주죠. -=== Integrity === +=== 진실성 === -Most people associate cryptography with keeping information secret, but another equally important goal is keeping information safe. Proper use of cryptographic hash functions can prevent accidental or malicious data corruption. +대부분의 사람들은 크립토그래피를 어떤 정보를 비밀스럽게 숨기는 정도로 생각합니다. 그러나 크립토그래피의 진정한 목적은 정보를 보안하는 것이죠. 크립토그래피로 보호되는 hash는 데이터가 공격받거나 지워질 위험으로부터 보호해줍니다. -A SHA1 hash can be thought of as a unique 160-bit ID number for every string of bytes you'll encounter in your life. Actually more than that: every string of bytes that any human will ever use over many lifetimes. +SHA1 hash는 고유의 160-비트 ID 번호로 생각하시면 됩니다. 그리고 이 번호는 당신이 평생, 또는 열번의 삶을 살 정도의 시간에, 쓸 byte에 부여되는 번호이기에 보안이 철저합니다. -As a SHA1 hash is itself a string of bytes, we can hash strings of bytes containing other hashes. This simple observation is surprisingly useful: look up 'hash chains'. We'll later see how Git uses it to efficiently guarantee data integrity. +SHA1 hash 자체 역시 byte로 구성되어 있기에 SHA1 hash의 hash를 만드는 것도 가능합니다. 이건 생각보다 유용한 기능입니다: 'hash chains'를 한번 살펴보세요. 우리는 나중에 Git이 이 기능을 어떻게 사용해서 효율적으로 데이터를 보호하는지 살펴보겠습니다. -Briefly, Git keeps your data in the `.git/objects` subdirectory, where instead of normal filenames, you'll find only IDs. By using IDs as filenames, as well as a few lockfiles and timestamping tricks, Git transforms any humble filesystem into an efficient and robust database. +짧게 말하자면, Git은 당신의 모든 데이터를 `.git/objects`섭디렉토리에 저장합니다. 그리고 보통의 파일이름대신 각 파일에 지정된 ID를 통해서 이 파일들을 찾을 수 있습니다. 그렇기에 Git은 보통의 파일시스템을 뭔가 굉장히 효율적인 데이터베이스로 변화시켜줍니다. -=== Intelligence === +=== 똑똑함 === -How does Git know you renamed a file, even though you never mentioned the fact explicitly? Sure, you may have run *git mv*, but that is exactly the same as a *git rm* followed by a *git add*. +어떻게 Git이 당신이 파일의 이름을 변경할 때 Git에게 이름을 바꾼다 말한적도 없는데 알수 있을까요? *git mv*를 실행할수도 있겠지만 그것은 *git rm*을 사용하고 *git add*를 사용하는 것과 같습니다. -Git heuristically ferrets out renames and copies between successive versions. In fact, it can detect chunks of code being moved or copied around between files! Though it cannot cover all cases, it does a decent job, and this feature is always improving. If it fails to work for you, try options enabling more expensive copy detection, and consider upgrading. +Git은 단순화된 지침으로 재설정된 파일명을 찾아내고 버전사이의 카피들을 만들어냅니다. Git은 코드들이 옮겨지고 카피되고 지워질 경우를 다 알아낼수 있죠. 모든 경우의 수를 다 알수는 없겠지만, Git은 대부분을 알아채고 있고 이 자동화된 기능은 날이 갈수록 발전하고 있습니다. -=== Indexing === -For every tracked file, Git records information such as its size, creation time and last modification time in a file known as the 'index'. To determine whether a file has changed, Git compares its current stats with those cached in the index. If they match, then Git can skip reading the file again. +=== 색인화 === -Since stat calls are considerably faster than file reads, if you only edit a -few files, Git can update its state in almost no time. +Git은 Git이 트랙킹하는 모든 파일들의 크기, 생성된 시간, 마지막 편집시간을 색인 (index)를 이용해서 기록하여 둡니다. 만약에 어떤 파일에 작업하여 변화가 생겼다면 Git은 현 파일상태와 인덱스에 저장되어있는 상태를 비교하여 파일의 변화를 감지합니다. 만약에 서로간의 차이가 없다면 Git은 그 파일이 가장 최신버전으로 업데이트되었다고 생각하고 더 이상 읽지 않습니다. -We stated earlier that the index is a staging area. Why is a bunch of file -stats a staging area? Because the add command puts files into Git's database -and updates these stats, while the commit command, without options, creates a -commit based only on these stats and the files already in the database. +인덱스 정보를 읽는 작업은 파일을 읽는 것보다는 훨씬 빠르게 진행되니 당신이 한 작업들은 Git이 아주 빠르게 업데이트 해줄 것입니다. -=== Git's Origins === +인덱스는 마치 중간 대기 구역과 같다고 말씀드린 적이 있습니다. 왜 그렇게 얘기 했을까요? *Add* 명령어는 파일들을 순전히 업데이트 시켜 데이터베이스에 업데이트 하지만 +*commit*은 (별도의 옵션을 사용하지 않는다는 전제하에) 자체적인 로컬데이터베이스에 있는 파일들에 대한 commit만 진행하지요. -This http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] describes the chain of events that led to Git. The entire thread is a fascinating archaeological site for Git historians. +=== Git의 근원 === -=== The Object Database === +http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] 에서 Git의 역사를 나열하여 설명해줍니다. Git의 역사학자들에게 정말 흥미있는 웹사이트지요. -Every version of your data is kept in the 'object database', which lives in the -subdirectory `.git/objects`; the other residents of `.git/` hold lesser data: -the index, branch names, tags, configuration options, logs, the current -location of the head commit, and so on. The object database is elementary yet -elegant, and the source of Git's power. +=== 오브젝트 데이터베이스 === -Each file within `.git/objects` is an 'object'. There are 3 kinds of objects -that concern us: 'blob' objects, 'tree' objects, and 'commit' objects. +데이터의 모든 버전은 '오브젝트 데이터베이스'에 보관되며, 이 데이터베이스는 `.git/objects`의 섭디렉토리에 상주하고 있습니다. `.git/`에 있는 다른 파일들은 더 적은 정보를 +담고 있지요 (인덱스, branch 이름, 태그, 설정 정보, 로그, head commit의 위치 등). 오브젝트 데이터베이스는 Git의 기본이지만 우아하고 또 Git의 힘의 원천입니다. -=== Blobs === +`.git/objects'에 있는 파일들은 각각 오브젝트입니다. 그리고 크게 세가지 오브젝트로 나눌수 있습니다: +'blob' 오브젝트, 'tree' 오브젝트, and 'commit' 오브젝트. -First, a magic trick. Pick a filename, any filename. In an empty directory: +=== Blob 오브젝트 === + +첫째, 마술을 보여드리겠습니다. 우선 아무 파일 이름을 선택하십시오. 빈 디렉토리에서 : $ echo sweet > YOUR_FILENAME $ git init $ git add . $ find .git/objects -type f -You'll see +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+. ++.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+ 을 보게 될 것입니다. -How do I know this without knowing the filename? It's because the -SHA1 hash of: +저는 파일이름을 알지도 못하는데 이걸 제가 어떻게 알까요? 왜냐하면 "blob" SP "6" NUL "sweet" LF -is aa823728ea7d592acc69b36875a482cdf3fd5c8d, -where SP is a space, NUL is a zero byte and LF is a linefeed. You can verify -this by typing: +의 SHA1 hash 는 aa823728ea7d592acc69b36875a482cdf3fd5c8d 이고, +SP 는 공간이며, NUL 는 0 바이트이고, LF는 라인피드이기 때문입니다. 직접 확인해보시려면 다음 명령어를 입력하세요: $ printf "blob 6\000sweet\n" | sha1sum -Git is 'content-addressable': files are not stored according to their filename, -but rather by the hash of the data they contain, in a file we call a 'blob -object'. We can think of the hash as a unique ID for a file's contents, so -in a sense we are addressing files by their content. The initial `blob 6` is -merely a header consisting of the object type and its length in bytes; it -simplifies internal bookkeeping. +Git은 콘텐츠 주소를 지정하는 것이 가능합니다: 파일은 파일 이름에 따라 저장되지 않습니다. +대신에 hash로 저장이 되며 이런 정보는 blob 오브젝트라고 불리우는 곳에 저장되어 있지요. +우리는 hash를 파일 내용에 대한 고유 ID로 생각할 수 있습니다. 그래서 +어떤 의미에서 우리는 파일의 내용에 따라 주소를 지정하는 것으로 생각이 가능합니다. 초기`blob 6`는 +오브젝트 타입과 크기를 저장해 놓은 header나 다름없습니다; 단지 내부 부기를 단순화합니다. -Thus I could easily predict what you would see. The file's name is irrelevant: -only the data inside is used to construct the blob object. +따라서 저는 당신이 보게 될 것을 쉽게 예측할 수 있었습니다. 파일 이름은 관련이 없습니다. +내부 데이터만을 이용해 blob 오브젝트를 구성하는게 가능합니다. -You may be wondering what happens to identical files. Try adding copies of -your file, with any filenames whatsoever. The contents of +.git/objects+ stay -the same no matter how many you add. Git only stores the data once. +그러면 당신은 동일한 파일이 어떻게되는지 궁금 할 수 있습니다. 우선 아무런 파일 이름을 사용해 복사본을 추가해보십시오. ++ .git / objects +의 내용은 몇개의 복사본을 추가해도 동일합니다. Git은 데이터를 한 번만 저장합니다. -By the way, the files within +.git/objects+ are compressed with zlib so you -should not stare at them directly. Filter them through -http://www.zlib.net/zpipe.c[zpipe -d], or type: +별개로, + .git / objects + 내의 파일은 zlib로 압축되어 있으므로 +그들을 직접 보지 마십시오. http://www.zlib.net/zpipe.c[zpipe -d] 를 통해 필터링을 해서 +보시던지, 아니면 다음 명령어를 실행해 보시면 됩니다.: $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d -which pretty-prints the given object. +주어진 오브젝트를 예쁘게 인쇄해줍니다. -=== Trees === +=== Tree 오브젝트 === -But where are the filenames? They must be stored somewhere at some stage. -Git gets around to the filenames during a commit: +그러나 파일 이름은 어디에 간거죠? 그들은 어떤 단계에서 어딘가에 저장되어야합니다. +Git은 커밋 중에 파일 이름을 찾습니다. $ git commit # Type some message. $ find .git/objects -type f +이제 3 개의 개체를 보게 될 것입니다. 이번에는 당신이 선택한 파일 이름에 부분적으로 의존하기 때문에 두 개의 새 파일이 무엇인지 제가 말씀드릴 수 없습니다. ``rose''를 파일이름을 지정한 것으로 가정하여 진행하겠습니다. 그렇게 설정하시지 않은 경우 기록을 다시 작성하여 그렇게 지정한 것처럼 보이게 할 수 있습니다. + You should now see 3 objects. This time I cannot tell you what the 2 new files are, as it partly depends on the filename you picked. We'll proceed assuming you chose ``rose''. If you didn't, you can rewrite history to make it look like you did: $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose' $ find .git/objects -type f -Now you should see the file -+.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+, because this is the -SHA1 hash of its contents: +그럼 이제 +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+를 보실 수 있을겁니다. 왜냐하면 이것이 +SHA1 hash이기 때문입니다: "tree" SP "32" NUL "100644 rose" NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d -Check this file does indeed contain the above by typing: + +다음을 입력하여 이 파일에 실제로 위 내용이 포함되어 있는지 확인하십시오. $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch -With zpipe, it's easy to verify the hash: +zpipe으로 이 hash를 확인하는 것이 아마 쉬운 방법일 겁니다: $ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum -Hash verification is trickier via cat-file because its output contains more -than the raw uncompressed object file. +Hash 확인은 cat-file로는 좀 어려울 수도 있습니다. 왜냐하면 압축되지 않은 원래의 파일보다 더 많은 파일을 +포함하고 있을 수 있기 때문입니다. + This file is a 'tree' object: a list of tuples consisting of a file type, a filename, and a hash. In our example, the file type is 100644, which @@ -141,32 +138,28 @@ delete them now to make our toy example easier to follow: $ git reflog expire --expire=now --all $ git prune -For real projects you should typically avoid commands like this, as you are -destroying backups. If you want a clean repository, it is usually best to make -a fresh clone. Also, take care when directly manipulating +.git+: what if a Git -command is running at the same time, or a sudden power outage occurs? -In general, refs should be deleted with *git update-ref -d*, -though usually it's safe to remove +refs/original+ by hand. +실제 프로젝트의 경우 일반적으로 이와 같은 명령을 피해야합니다. 이 명령어들은 백업들을 지울 수 있기 때문이죠. +깨끗한 repository를 원한다면 일반적으로 새로운 클론을 새롭게 만드는 것이 좋습니다. 그리고 +.git+을 조작할때는 +주의하십시오: 만약에 여러가지 커맨드들이 동시에 실행 중이거나 갑작스러운 정전이 발생하면 안되잖아요. +일반적으로 refs는 *git update-ref -d*로 삭제해야합니다. 그래도 +refs / original+를 수동으로 제거하는 것이 안전하긴 하지만요. -=== Commits === +=== Commit 오브젝트 === -We've explained 2 of the 3 objects. The third is a 'commit' object. Its -contents depend on the commit message as well as the date and time it was -created. To match what we have here, we'll have to tweak it a little: +우리는 3 개의 오브젝트들 중 2 개를 설명했습니다. 세 번째는 'commit'오브젝트입니다. 이 오브젝트의 +내용은 commit 메시지와 날짜 및 시간에 따라 다릅니다. +여기에있는 것과 일치 시키려면 약간의 조정이 필요합니다. - $ git commit --amend -m Shakespeare # Change the commit message. + $ git commit --amend -m Shakespeare # Commit 메시지를 바꿉니다. $ git filter-branch --env-filter 'export GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800" GIT_AUTHOR_NAME="Alice" GIT_AUTHOR_EMAIL="alice@example.com" GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800" GIT_COMMITTER_NAME="Bob" - GIT_COMMITTER_EMAIL="bob@example.com"' # Rig timestamps and authors. + GIT_COMMITTER_EMAIL="bob@example.com"' # 타임스탬프와 저자를 바꿉니다. $ find .git/objects -type f -You should now see -+.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+ -which is the SHA1 hash of its contents: +그럼 이제 +.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+ 를 보게될것 입니다. "commit 158" NUL "tree 05b217bb859794d08bb9e4f7f04cbda4b207fbe9" LF @@ -175,40 +168,37 @@ which is the SHA1 hash of its contents: LF "Shakespeare" LF -As before, you can run zpipe or cat-file to see for yourself. - -This is the first commit, so there are no parent commits, but later commits -will always contain at least one line identifying a parent commit. - -=== Indistinguishable From Magic === - -Git's secrets seem too simple. It looks like you could mix together a few shell scripts and add a dash of C code to cook it up in a matter of hours: a melange of basic filesystem operations and SHA1 hashing, garnished with lock files and fsyncs for robustness. In fact, this accurately describes the earliest versions of Git. Nonetheless, apart from ingenious packing tricks to save space, and ingenious indexing tricks to save time, we now know how Git deftly changes a filesystem into a database perfect for version control. - -For example, if any file within the object database is corrupted by a disk -error, then its hash will no longer match, alerting us to the problem. By -hashing hashes of other objects, we maintain integrity at all levels. Commits -are atomic, that is, a commit can never only partially record changes: we can -only compute the hash of a commit and store it in the database after we already -have stored all relevant trees, blobs and parent commits. The object -database is immune to unexpected interruptions such as power outages. - -We defeat even the most devious adversaries. Suppose somebody attempts to -stealthily modify the contents of a file in an ancient version of a project. To -keep the object database looking healthy, they must also change the hash of the -corresponding blob object since it's now a different string of bytes. This -means they'll have to change the hash of any tree object referencing the file, -and in turn change the hash of all commit objects involving such a tree, in -addition to the hashes of all the descendants of these commits. This implies the -hash of the official head differs to that of the bad repository. By -following the trail of mismatching hashes we can pinpoint the mutilated file, -as well as the commit where it was first corrupted. - -In short, so long as the 20 bytes representing the last commit are safe, -it's impossible to tamper with a Git repository. - -What about Git's famous features? Branching? Merging? Tags? -Mere details. The current head is kept in the file +.git/HEAD+, -which contains a hash of a commit object. The hash gets updated during a commit -as well as many other commands. Branches are almost the same: they are files in -+.git/refs/heads+. Tags too: they live in +.git/refs/tags+ but they -are updated by a different set of commands. + +이전과 마찬가지로 zpipe 또는 cat-file을 실행하여 직접 확인할 수 있습니다. +이것은 첫 번째 commit이므로 부모 commit이 없지만 이제 나중에 commit을 할때마다 +항상 부모 commit을 식별하는 한 줄이 포함될것 입니다. + +=== 마술과 분간이 안되는 프로그램 === + +Git의 비밀은 너무 단순 해 보입니다. 몇 시간 안에 몇 개의 셸 스크립트를 혼합하고 C 코드를 추가하여 몇 시간 만에 만들 수있는 것 같아 보입니다. 결국에 Git은 견고성을 위해 잠금 파일과 fsync로 장식 된 기본 파일 시스템 작업과 SHA1 해싱의 혼합으로 구성된 프로그램입니다. 실제로 이것은 Git의 초기 버전을 정확하게 설명합니다. 그럼에도 불구하고 공간을 절약하기위한 독창적인 패킹 트릭과 시간을 절약하기위한 독창적 인 인덱싱 트릭을 포함해 이제 우리는 Git이 버전 컨트롤을 위한 완벽한 데이터베이스로 거듭나게 되는지 알게되었습니다. + +예를 들어, 오브젝트 데이터베이스 내의 파일이 디스크에 의해 손상된 경우 +오류가 발생하면 hash가 더 이상 일치하지 않아 문제를 알려줍니다. +기존 hash에 다른 hash를 지정해 주면서, 우리는 모든 수준에서 무결성을 유지합니다. Commit은 부분적으로 +파일을 관리하지않고 전체적으로 프로젝트를 관리하여줍니다. +Commit의 hash를 계산하고서 모든 tree, blob 과 부모 commit들을 저장한 후에 데이터베이스에 저장합니다. +오브젝트 데이터베이스는 정전과 같은 예상치 못한 방해에 영향을받지 않습니다. + +우리는 Git으로 가장 사악한 적도 물리칠수 있습니다. 만약에 누군가가 +아주 예전 버전의 프로젝트에서 파일 내용을 은밀하게 수정한다고 생각해봅시다. +오브젝트 데이터베이스를 정상 상태처럼 보이게 유지하려면 해당 데이터베이스의 해시도 변경해야 할겁니다. +이 말은 해당 파일을 참조하는 tree 오브젝트의 hash도 변경해야한다는 의미입니다. +그리고 차례로 그러한 tree를 포함하는 모든 commit 오브젝트의 hash도 변경해야 한다는 거지요. +이러면 해당 파일 이후의 commit모두 변경을 해야한다는 말이됩니다. +이것은 공식 헤드의 hash는 나쁜 repository의 hash와 달라질 수 밖에 없다는 것입니다. 그러니 +일치하지 않는 hash의 흔적을 따라 나쁜의도로 변경된 파일을 정확히 찾아 낼 수 있습니다. +처음에 손상된 commit도 마찬가지로 찾을 수 있습니다. + +짧게 말하자면, 마지막 commit을 나타내는 20 바이트가 안전하다면 +Git repository를 임의로 아무에게도 들키지 않게 조작하는 것은 불가능합니다. + +Git의 유명한 기능은 또 어떻습니까? branch 만들기? 병합하기? 태깅하기? +세부 사항. 현재 head는 + .git / HEAD + 파일에 보관됩니다. +commit 오브젝트의 hash를 포함합니다. Commit 중에 hash가 업데이트됩니다. +Branch는 거의 동일합니다: 그것들은 +.git/refs/heads+에 저장된 파일들 입니다. 태그도 +.git/refs/tags +에 있지만 +다른 명령어들로 업데이트됩니다. \ No newline at end of file diff --git a/ko/translate.txt b/ko/translate.txt index d1842cdf..f3bdbb1b 100644 --- a/ko/translate.txt +++ b/ko/translate.txt @@ -1,15 +1,13 @@ -== Appendix B: Translating This Guide == +== 부록 B: 이 가이드를 번역하기 == -I recommend the following steps for translating this guide, so my scripts can -quickly produce HTML and PDF versions, and all translations can live in the -same repository. +다음 절차들을 따라하셔야 제 프로그램이 자동으로 빠르게 HTML과 PDF 버전의 번역본을 만들수 있습니다. -Clone the source, then create a directory corresponding to the target -language's IETF tag: see +우선 원본이 되는 소스를 클론하시고 폴더를 만드시는데, 폴더명을 IETF에 기재되어 있는 태그를 쓰시기 바랍니다: +다음 링크에 들어가셔서 확인하세요, http://www.w3.org/International/articles/language-tags/Overview.en.php[the W3C -article on internationalization]. For example, English is "en" and Japanese is -"ja". In the new directory, and translate the +txt+ files from the "en" -subdirectory. +article on internationalization]. 예를 들자면, 영어의 태그는 "en"이고, 일본어는 "ja"이며, 국어는 "ko"입니다. +그리고 새로운 디렉토리에서 "en"에 들어있는 원본 txt를 번역하시면 됩니다. (번역주: 영어를 못하시고 국어를 하실수 있다면 본 가이드를 쓰시면 되겠지만 그럴 확률이 거의 없겠죠) + For instance, to translate the guide into http://en.wikipedia.org/wiki/Klingon_language[Klingon], you might type: diff --git a/makeover b/makeover index c3572de3..fa6a57f9 100755 --- a/makeover +++ b/makeover @@ -1,4 +1,4 @@ -#!/bin/bash +#!/usr/bin/env bash # Extract table of contents from index.html and delete preface link. BOOKDIR=book-$1 @@ -9,37 +9,31 @@ case $1 in ;; esac -gawk ' -/
/ { - print $0 - getline - print $0 - print "
  • '"$TITLE"'
    • " - getline - while (!match($0, "
    ")) { - gsub("pr01.html", "index.html") - print $0 - getline - } - print $0 - exit -} -' < $BOOKDIR/index.html > toc.tmp +# Older AsciiDoc versions put newlines in their output. +# To get them to work with the following, first minify the HTML output. +cat $BOOKDIR/index.html \ + | grep -o '
    .*' \ + | sed 's!
    .*!!' \ + | sed 's!!index.html!g' \ + | sed 's!
  • !
  • '"$TITLE"'
    • &!' \ + > toc.tmp # For every file except the index... for FILE in $BOOKDIR/*.html do - sed '//a <link href="http://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet" type="text/css">' -i $FILE + sed '/<title>/a <link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet" type="text/css">' -i $FILE if [ $FILE != "$BOOKDIR/index.html" ] then # Prepend "Git Magic - " to titles of all pages. sed '/<title>/ s/<title>/&'"$TITLE"' - /' -i $FILE sed 's/pr01\.html/index.html/g' -i $FILE + # Insert newline after `body` tag. + sed 's/<body[^>]*>/&\n/' -i $FILE # Paste ToC into beginning and add div section with class content for CSS. - sed '/<body/{n; r toc.tmp + sed '/<body/{r toc.tmp a <div class="content"> }' -i $FILE - sed '/^<\/body/i </div>' -i $FILE + sed 's!</body>!</div>&!' -i $FILE fi done diff --git a/pl/basic.txt b/pl/basic.txt index 1f3f7da5..9171def8 100644 --- a/pl/basic.txt +++ b/pl/basic.txt @@ -78,7 +78,7 @@ Korzystając ponownie z analogii do gier komputerowych: - *`git reset --hard`*: załaduj jakiś starszy stan gry i skasuj wszystkie nowsze niż właśnie ładowany. -- *`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 jako osobna gałęź ('branch'), reprezentującym alternatywną rzeczywistość. <<branch,Wrócimy do tego później>> +- *`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 jako osobna gałąź ('branch'), reprezentującym alternatywną rzeczywistość. <<branch,Wrócimy do tego później>> Jeśli chcesz, możesz przywrócić jedynie wybrane pliki lub katalogi poprzez dodanie ich nazw do polecenia: @@ -115,7 +115,7 @@ Kopię projektu zarządzanego za pomocą Gita uzyskasz poleceniem: $ git clone git://ścieżka/do/projektu -By na przykład zładować wszystkie dane, których użyłem do stworzenia tej strony skorzystaj z: +By na przykład załadować wszystkie dane, których użyłem do stworzenia tej strony skorzystaj z: $ git clone git://git.or.cz/gitmagic.git @@ -129,7 +129,7 @@ Jeśli posiadasz już kopię projektu wykonaną za pomocą *git clone*, możesz === Szybka publikacja === -Przypuśćmy, że napisałaś skrypt i chcesz go udostępnić innym. Mogłabyś poprosić ich, by zładowali go bezpośrednio z twojego komputera. Jeśli jednak zrobią to podczas gdy ty jeszcze 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. +Przypuśćmy, że napisałaś skrypt i chcesz go udostępnić innym. Mogłabyś poprosić ich, by załadowali go bezpośrednio z twojego komputera. Jeśli jednak zrobią to podczas gdy ty jeszcze 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. Aby wykonać to za pomocą GIT, wejdź do katalogu w którym znajduje się twój skrypt: @@ -141,7 +141,7 @@ Następnie poproś twych użytkowników o wykonanie: $ git clone twój.komputer:/ścieżka/do/skryptu -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: +by zał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: $ git clone git://twój.komputer/ścieżka/do/skryptu @@ -173,13 +173,13 @@ Za każdym razem uzyskane informacje są równocześnie patchem, który poprzez $ git whatchanged --since="2 weeks ago" -Jeśli chcę sprawdzić listę zmian jakiegoś repozytorium, często korzystam 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ą. +Jeśli chcę sprawdzić listę zmian jakiegoś repozytorium, często korzystam 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ą. === Ćwiczenie === 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ć? -Istnieją przynajmniej 3 rozwiązania. Załóżmy że znajdujemy się obecnie w D: +Istnieją przynajmniej 3 rozwiązania. Załóżmy, że znajdujemy się obecnie w D: 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: diff --git a/pl/branch.txt b/pl/branch.txt index c4854226..927f722a 100644 --- a/pl/branch.txt +++ b/pl/branch.txt @@ -2,9 +2,9 @@ Szybkie, natychmiastowe działanie poleceń 'branch' i 'merge', to jedne z najbardziej zabójczych właściwości Gita. -*Problem*: Zewnętrzne faktory narzucają konieczność zmiany kontekstu. Poważne błędy w opublikowanej wersji ujawniły się bez ostrzeżenia. Skrócono termin opublikowania pewnej właściwości. Autor, którego pomocy potrzebujesz w jednej z kluczowych sekcji postanawia opóścić projekt. We wszystkich tych przypadkach musisz natychmiastowo zaprzestać bieżących prac i skoncentrować się nad zupełnie innymi zadaniami. +*Problem*: Zewnętrzne faktory narzucają konieczność zmiany kontekstu. Poważne błędy w opublikowanej wersji ujawniły się bez ostrzeżenia. Skrócono termin opublikowania pewnej właściwości. Autor, którego pomocy potrzebujesz w jednej z kluczowych sekcji postanawia opuścić projekt. We wszystkich tych przypadkach musisz natychmiastowo zaprzestać bieżących prac i skoncentrować się nad zupełnie innymi zadaniami. -Przerwanie toku myślenia nie jest dobre dla produktywności, a czym większa różnica w kontekście, tym większe straty. Używając centralnych systemów kontroli wersji musielibyśmy najpierw zładować świeżą kopię roboczą z serwera. W systemach rozproszonych wygląda to dużo lepiej, ponieważ możemy żądaną wersje sklonować lokalnie +Przerwanie toku myślenia nie jest dobre dla produktywności, a czym większa różnica w kontekście, tym większe straty. Używając centralnych systemów kontroli wersji musielibyśmy najpierw załadować świeżą kopię roboczą z serwera. W systemach rozproszonych wygląda to dużo lepiej, ponieważ możemy żądaną wersje sklonować lokalnie Jednak klonowanie również niesie za sobą kopiowanie całego katalogu roboczego jak i całej historii projektu aż do żądanego punktu. Nawet jeśli Git redukuje wielkość przez podział danych i użycie twardych dowiązań, wszystkie pliki projektu muszą zostać odtworzone w nowym katalogu roboczym. @@ -175,7 +175,7 @@ Można to porównać do chwilowego przełączenia kanału telewizyjnego, by spra $ git stash -Polecenie to zabezpiecza aktualny stan w tymczasowym miejscu ('stash' = ukryj) i przywraca poprzedni stan. Twój katalog roboczy wygląda dokładnie tak, jak wyglądał zanim zacząłaś edycję. Teraz możesz poprawiać błędy, zładować zmiany z centralnego repozytorium ('pull') i tak dalej. Jeśli chcesz powrócić z powrotem do ukrytego ('stashed') stanu, wpisz: +Polecenie to zabezpiecza aktualny stan w tymczasowym miejscu ('stash' = ukryj) i przywraca poprzedni stan. Twój katalog roboczy wygląda dokładnie tak, jak wyglądał zanim zacząłaś edycję. Teraz możesz poprawiać błędy, załadować zmiany z centralnego repozytorium ('pull') i tak dalej. Jeśli chcesz powrócić z powrotem do ukrytego ('stashed') stanu, wpisz: $ git stash apply # Prawdopodobnie będziesz musiał rozwiązać konflikty. diff --git a/pl/clone.txt b/pl/clone.txt index 685d95f8..05c9d791 100644 --- a/pl/clone.txt +++ b/pl/clone.txt @@ -1,6 +1,6 @@ == Klonowanie == -W starszych systemach kontroli wersji polecenie 'checkout' stanowi standardową operacje pozyskiwania danych. Otrzymasz nią zbiór plików konkretnej wersji. +W starszych systemach kontroli wersji polecenie 'checkout' stanowi standardową operację pozyskiwania danych. Otrzymasz nią zbiór plików konkretnej wersji. W Git i innych rozproszonych systemach standardowo służy temu operacja 'clone'. By pozyskać dane, tworzysz najpierw klon całego repozytorium. Lub inaczej mówiąc, otrzymujesz lustrzane odbicie serwera. Wszystko, co można zrobić w centralnym repozytorium, możesz również robić z klonem. @@ -12,7 +12,7 @@ Utwórz repozytorium Gita w wykonaj 'commit' twoich danych na jednym z komputer $ git clone drugi.komputer:/ścieżka/do/danych -by otrzymać drugą kopie danych i jednocześnie utworzyć repozytorium Gita na drugim komputerze. Od teraz poleceniem: +by otrzymać drugą kopię danych i jednocześnie utworzyć repozytorium Gita na drugim komputerze. Od teraz poleceniem: $ git commit -a $ git pull drugi.komputer:/ścieżka/do/danych HEAD @@ -34,7 +34,7 @@ Na centralnym serwerze utwórz gołe ('bare') repozytorium w jakimkolwiek katalo $ git --bare init $ touch proj.git/git-daemon-export-ok -W razie konieczności, wystartuj daemon Gita: +W razie konieczności wystartuj daemon Gita: $ git daemon --detach # ponieważ, gdyby uruchomiony był wcześniej @@ -70,7 +70,7 @@ Programiści potrzebują dostępu poprzez SSH dla wykonania poleceń 'pull' i 'p $ git clone git://główny.serwer/ścieżka/do/projektu.git -Protokół GIT przypomina HTTP: nie posiada autentyfikacji, a więc każdy może skopiować dane. Przy ustawieniach standardowych wykonanie 'push' za pomocą protokołu GIT jest zdezaktywowane. +Protokół GIT przypomina HTTP: nie posiada uwierzytelniania, a więc każdy może skopiować dane. Przy ustawieniach standardowych wykonanie 'push' za pomocą protokołu GIT jest zdezaktywowane. === Utajnienie źródła === @@ -90,7 +90,7 @@ Dlaczego wprowadziliśmy polecenie 'push', a nie pozostaliśmy przy znanym nam j W każdym bądź razie, nawet jeśli nawet mogło by to zadziałać, odradzam z korzystania z funkcji 'push' w ten sposób. Poprzez samo posiadanie katalogu roboczego na serwerze mogłoby powstać wiele nieścisłości. -Krótko mówiąc, podczas gdy uczysz się korzystania z Git, korzystaj z polecenia 'push' tylko, gdy celem jest repozytorium 'bare', w wszystkich innych wypadkach z 'pull'. +Krótko mówiąc, podczas gdy uczysz się korzystania z Git, korzystaj z polecenia 'push' tylko, gdy celem jest repozytorium 'bare', we wszystkich innych wypadkach z 'pull'. === Rozwidlenie projektu === diff --git a/pl/drawbacks.txt b/pl/drawbacks.txt index 1d15d024..e3b08773 100644 --- a/pl/drawbacks.txt +++ b/pl/drawbacks.txt @@ -14,7 +14,7 @@ Korzystanie z Gita pod Microsoft Windows może być frustrujące: - http://cygwin.com/[Cygwin], unixoidalne środowisko dla Windowsa posiada http://cygwin.com/packages/git/[port Gita]. -- http://code.google.com/p/msysgit/[Git dla MSys] jest jedną z alternatyw, niektóre polecenia wymagają jednak poprawek. +- https://gitforwindows.org/[Git dla Windows] jest jedną z alternatyw, niektóre polecenia wymagają jednak poprawek. === Pliki niepowiązane === @@ -84,7 +84,7 @@ Jeśli na przykład użytkownik wykonałby polecenie *git log*, zostałby poinfo Każdy inicjujący 'commit' byłby pochodną tego zerowego 'commit'. -Niestety występuje jeszcze kilka innych problemów. Jeśli chcemy scalić kilka 'branches' o różniących sie inicjalnych 'commits' i przeprowadzić 'rebase', musimy ingerować ręcznie. +Niestety występuje jeszcze kilka innych problemów. Jeśli chcemy scalić kilka 'branches' o różniących się inicjalnych 'commits' i przeprowadzić 'rebase', musimy ingerować ręcznie. === Charakterystyka zastosowania === diff --git a/pl/grandmaster.txt b/pl/grandmaster.txt index ff380f8d..f066d77a 100644 --- a/pl/grandmaster.txt +++ b/pl/grandmaster.txt @@ -39,7 +39,7 @@ Jeśli jesteś już zadowolony z wyniku, wpisz: by dokonać wybranych zmian. Uważaj tylko, by nie skorzystać z opcji *-a*, ponieważ wtedy git dokona 'commit' zawierający wszystkie zmiany. -A co, jeśli pracowałaś nad wieloma danymi w wielu różnych miejscach? Sprawdzenie każdej danej z osobna jest zarówno rustrujące jak i męczące. W takim wypadku skorzystaj z *git add -i*, obsługa tego polecenia może nie jest zbyt łatwa, za to jednak bardzo elastyczna. Kilkoma naciśnięciami klawiszy możesz wiele zmienionych plików dodać ('stage') albo usunąć z 'commit' ('unstage'), jak również sprawdzić, czy dodać zmiany dla poszczególnych plików. Alternaywnie możesz skorzystać z *git commit \--interactive*, polecenie to wykona automatycznie 'commit' gdy skończysz. +A co, jeśli pracowałaś nad wieloma danymi w wielu różnych miejscach? Sprawdzenie każdej danej z osobna jest zarówno frustrujące, jak i męczące. W takim wypadku skorzystaj z *git add -i*, obsługa tego polecenia może nie jest zbyt łatwa, za to jednak bardzo elastyczna. Kilkoma naciśnięciami klawiszy możesz wiele zmienionych plików dodać ('stage') albo usunąć z 'commit' ('unstage'), jak również sprawdzić, czy dodać zmiany dla poszczególnych plików. Alternaywnie możesz skorzystać z *git commit \--interactive*, polecenie to wykona automatycznie 'commit' gdy skończysz. === Index: rusztowanie Gita === @@ -55,7 +55,7 @@ Identyfikator 'HEAD' zachowuje się jak kursor, który zwykle wskazuje na najmł $ git reset HEAD~3 -przesunie identyfikator 'HEAD' o 3 'commits' spowrotem. Spowoduje to, że wszystkie następne komendy Gita będą reagować, jakby tych trzech ostatnich 'commits' wogóle nie było, podczas gdy twoje dane zostaną w przyszłości. Na stronach pomocy Gita znajdziesz więcej takich zastosowań. +przesunie identyfikator 'HEAD' o 3 'commits' z powrotem. Spowoduje to, że wszystkie następne komendy Gita będą reagować, jakby tych trzech ostatnich 'commits' wogóle nie było, podczas gdy twoje dane zostaną w przyszłości. Na stronach pomocy Gita znajdziesz więcej takich zastosowań. Ale jak teraz wrócić znów do przyszłości? Poprzednie 'commits' nic nie wiedzą o jej istnieniu. @@ -126,7 +126,7 @@ Ulubionym przedstawicielem jest +workdir/git-new-workdir+. Poprzez sprytne przel $ git-new-workdir istniejacy/repo nowy/katalog -Ten nowy katalog i znajdujące się w nim pliki można sobie wyobrazić jako klon, z tą różnicą, że ze względu na wspólną niepodzieloną historie obje wersje pozostaną zsynchronizowane. Synchronizacja za pomocą 'merge', 'push', czy 'pull' nie będzie konieczna. +Ten nowy katalog i znajdujące się w nim pliki można sobie wyobrazić jako klon, z tą różnicą, że ze względu na wspólną niepodzieloną historie obie wersje pozostaną zsynchronizowane. Synchronizacja za pomocą 'merge', 'push', czy 'pull' nie będzie konieczna. === Śmiałe wyczyny === diff --git a/pl/history.txt b/pl/history.txt index 6f604fc7..5da4362c 100644 --- a/pl/history.txt +++ b/pl/history.txt @@ -75,7 +75,7 @@ Teraz jednak historia w twoim lokalnym klonie jest chaotycznym pomieszaniem twoi To zadanie dla *git rebase*, jak opisano powyżej. W wielu przypadkach możesz skorzystać z przełącznika *--onto* by zapobiec interakcji. -Przeczytaj też *git help rebase* dla zapoznania sie z obszernymi przykładami tej zadziwiającej funkcji. Możesz również podzielić 'commits'. Możesz nawet przeorganizować 'branches' w repozytorium. +Przeczytaj też *git help rebase* dla zapoznania się z obszernymi przykładami tej zadziwiającej funkcji. Możesz również podzielić 'commits'. Możesz nawet przeorganizować 'branches' w repozytorium. Bądź ostrożny korzystając z 'rebase', to bardzo mocne polecenie. Zanim dokonasz skomplikowanych 'rebase', zrób backup za pomocą *git clone* diff --git a/pl/intro.txt b/pl/intro.txt index dd8e57e6..6c11d9ab 100644 --- a/pl/intro.txt +++ b/pl/intro.txt @@ -14,11 +14,11 @@ Niestety wymaże to poprzednio zapamiętaną wersję. To jak w grach starej szko Podczas edytowania dokumentu, by uchronić starą wersję, możesz poprzez wybranie 'zapisz jako ...' zapisać twój dokument pod inną nazwą lub zapamiętać w innym miejscu. Poza tym możesz go jeszcze spakować, by zaoszczędzić miejsce na dysku. Jest to prymitywna i pracochłonna forma kontroli wersji. Gry komputerowe robią tak już od długiego czasu, wiele z nich posiada tak automatycznie utworzone punkty opatrzone sygnaturą czasu. -Skomplikujmy teraz trochę cały ten problem. Powiedzmy, że posiadasz całą masę plików, które w jakiś sposób są ze sobą powiązane, na przykład kod źródłowy jakiegoś projektu lub pliki strony internetowej. Jeśli chcesz otrzymać starszą wersję musisz archiwizować cały katalog. Archiwizowanie w ten sposób wielu wersji jest pracochłonne i szybko może stać się kosztowne, zabierając niepotrzebnie miejsce na dysku. +Skomplikujmy teraz trochę cały ten problem. Powiedzmy, że posiadasz całą masę plików, które w jakiś sposób są ze sobą powiązane, na przykład kod źródłowy jakiegoś projektu lub pliki strony internetowej. Jeśli chcesz otrzymać starszą wersję, musisz archiwizować cały katalog. Archiwizowanie w ten sposób wielu wersji jest pracochłonne i szybko może stać się kosztowne, zabierając niepotrzebnie miejsce na dysku. Niektóre gry komputerowe składały się rzeczywiście z jednego katalogu pełnego plików. Gry ukrywały szczegóły przed graczem i prezentowały wygodny interfejs, do zarządzania różnymi wersjami katalogu. -Systemy kontroli wersji nie różnią się tutaj zbytnio. Wszystkie posiadają wygodne interfejsy, umożliwiającymi zarządzanie katalogami pełnymi plików. Możesz archiwizować stan katalogu tak często jak często zechcesz i później możesz do każdego z tych punktów powrócić. W przeciwieństwie jednak do gier, są one z reguły wszystkie zoptymalizowane pod kątem oszczędności pamięci. W większości przypadków tylko niewiele danych ulega zmianie pomiędzy dwoma wersjami, a same zmiany nie są zbyt obszerne. Oszczędność miejsca na dysku polega głównie na zapamiętywaniu jedynie różnic, a nie kopii całego katalogu. +Systemy kontroli wersji nie różnią się tutaj zbytnio. Wszystkie posiadają wygodne interfejsy, umożliwiającymi zarządzanie katalogami pełnymi plików. Możesz archiwizować stan katalogu tak często, jak często zechcesz i później możesz do każdego z tych punktów powrócić. W przeciwieństwie jednak do gier, są one z reguły wszystkie zoptymalizowane pod kątem oszczędności pamięci. W większości przypadków tylko niewiele danych ulega zmianie pomiędzy dwoma wersjami, a same zmiany nie są zbyt obszerne. Oszczędność miejsca na dysku polega głównie na zapamiętywaniu jedynie różnic, a nie kopii całego katalogu. === Kontrola rozproszona === @@ -26,32 +26,32 @@ Wyobraź sobie teraz bardzo trudną grę komputerową. Tak trudną, że wielu do W jaki sposób skonstruowałbyś taki system, który w prosty sposób byłby w stanie udostępnić osiągnięcia innych? I dodawał nowe? -Kiedyś każdy projekt korzystał z własnego scentralizowanego systemu kontroli wersji. Jeden serwer zapamiętywał wszystkie gry, nikt inny. Każdy gracz posiadał jedynie kilka zapamiętanych na swoim komputerze gier. Jeśli jakiś gracz chciał popchać grę trochę do przodu, musiał najpierw zładować z serwera jej aktualny stan, trochę pograć, zapisać własny stan, a następnie załadować na serwer, by mógł go wykorzystać ktoś inny. +Kiedyś każdy projekt korzystał z własnego scentralizowanego systemu kontroli wersji. Jeden serwer zapamiętywał wszystkie gry, nikt inny. Każdy gracz posiadał jedynie kilka zapamiętanych na swoim komputerze gier. Jeśli jakiś gracz chciał popchać grę trochę do przodu, musiał najpierw załadować z serwera jej aktualny stan, trochę pograć, zapisać własny stan, a następnie załadować na serwer, by mógł go wykorzystać ktoś inny. A gdy jakiś gracz z jakiegoś powodu chce otrzymać jakiś starszy stan? Może aktualnie zapamiętany stan gry nie jest do przejścia, bo ktoś na trzecim poziomie zapomniał zabrać jakiś obiekt, no i teraz próbują znaleźć stan od którego startując gra znowu stanie się możliwa do przejścia. Albo chcą porównać dwa stany, by sprawdzić ile któryś gracz włożył pracy. Istnieje wiele powodów, dla których można chcieć zobaczyć straszą wersję, rezultat jednak jest zawsze taki sam. Za każdym razem trzeba ściągnąć wszystkie dane z serwera. Czym więcej gier zostało zapamiętanych, tym więcej wymaga to komunikacji. -Nową generację systemów kontroli wersji, do których zalicza się również Git, nazywa się systemami rozproszonymi, mogą być one rozumiane jako uogólnienie systemów scentralizowanych. Jeśli gracze ładują teraz z serwera, otrzymują każdy zapisany stan, a nie tylko zapisany jako ostatni. Wygląda to jak tworzenie kopii lustrzanej serwera. +Nową generację systemów kontroli wersji, do których zalicza się również Git, nazywa się systemami rozproszonymi, mogą być one rozumiane jako uogólnienie systemów scentralizowanych. Jeśli gracze ładują teraz z serwera, otrzymują każdy zapisany stan, a nie tylko zapisany jako ostatni. Wygląda to, jak tworzenie kopii lustrzanej serwera. Stworzenie pierwszego klonu może wydać się drogie, przede wszystkim, jeśli projekt posiada długą historię, ale na dłuższy okres to się opłaci. Jedną z bezpośrednich zalet jest to, że kiedykolwiek potrzebny będzie nam jakiś starszy stan, komunikacja z głównym serwerem będzie zbędna. === Głupi przesąd === -Szeroko rozpowszechnianym nieporozumieniem jest opinia, że rozproszony system nie nadaje się dla projektów wymagających oficjalnego centralnego repozytorium. Nic bardziej mylnego. Fotografując kogoś nie kradniemy od razu jego duszy. Tym samym klonowanie centralnego repozytorium nie umniejsza jego znaczenia. +Szeroko rozpowszechnianym nieporozumieniem jest opinia, że rozproszony system nie nadaje się dla projektów wymagających oficjalnego centralnego repozytorium. Nic bardziej mylnego. Fotografując kogoś, nie kradniemy od razu jego duszy. Tym samym klonowanie centralnego repozytorium nie umniejsza jego znaczenia. Jednym z pierwszych pozytywnych skutków jest to, iż wszystko co potrafi scentralizowany system kontroli wersji, dobrze skonstruowany system rozproszony potrafi lepiej. Zasoby sieciowe są po prostu droższe niż zasoby lokalne. Nawet jeśli w późniejszym czasie dostrzeżemy pewne niedociągnięcia systemów rozproszonych, można powyższe przyjąć jako ogólną zasadę, unikając niestosownych porównań. -Mały projekt wykorzysta prawdopodobnie tylko ułamek możliwości systemu. Ale, by od razu z tego powodu korzystać z prostszego systemu, nie posiadającego możliwości późniejszej rozbudowy, to tak jak stosowanie rzymskich cyfr do przeprowadzania obliczeń na małych liczbach. +Mały projekt wykorzysta prawdopodobnie tylko ułamek możliwości systemu. Ale, by od razu z tego powodu korzystać z prostszego systemu, nieposiadającego możliwości późniejszej rozbudowy, to tak jak stosowanie rzymskich cyfr do przeprowadzania obliczeń na małych liczbach. -Ponadto możliwe, że twój projekt przerośnie początkowe oczekiwania. Używanie Gita od samego początku, to jak noszenie ze sobą szwajcarskiego scyzoryka, nawet gdy najczęściej służy do otwierania butelek. Być może pewnego dnia będziesz pilnie potrzebowała użyć śrubokręt, ucieszysz się, że masz przy sobie coś więcej niż tylko zwykły otwieracz. +Ponadto możliwe, że twój projekt przerośnie początkowe oczekiwania. Używanie Gita od samego początku to jak noszenie ze sobą szwajcarskiego scyzoryka, nawet gdy najczęściej służy do otwierania butelek. Być może pewnego dnia będziesz pilnie potrzebowała użyć śrubokrętu, ucieszysz się, że masz przy sobie coś więcej niż tylko zwykły otwieracz. === Kolizje przy scalaniu === Do przedstawienia tego tematu wykorzystanie analogii do gier komputerowych byłoby naciągane. Wyobraźmy sobie znowu, że edytujemy dokument. -Alicja dodaje linijkę na początku dokumentu, natomiast Bob linijkę na jego końcu. Obydwoje ładują swoje zmiany na serwer. Większość systemów automatycznie wybierze rozsądną drogę: zaakceptuje obie zmiany i połączy je ze sobą, tym samym obje poprawki wpłyną do dokumentu. +Alicja dodaje linijkę na początku dokumentu, natomiast Bob linijkę na jego końcu. Obydwoje ładują swoje zmiany na serwer. Większość systemów automatycznie wybierze rozsądną drogę: zaakceptuje obie zmiany i połączy je ze sobą, tym samym obie poprawki wpłyną do dokumentu. -Wyobraź sobie jednak, że Alicja i Bob dokonują zmian w tej samej linijce. W tym wypadku dalsza praca nie będzie możliwa bez ludzkiego udziału. Druga z osób, próbująca zładować dokument na serwer, zostanie poinformowana o wystąpieniu konfliktu podczas łączenia ('merge') i musi zadecydować, którą ze zmian przyjąć, ewentualnie ponownie zrewidować całą linijkę. +Wyobraź sobie jednak, że Alicja i Bob dokonują zmian w tej samej linijce. W tym wypadku dalsza praca nie będzie możliwa bez ludzkiego udziału. Druga z osób, próbująca załadować dokument na serwer, zostanie poinformowana o wystąpieniu konfliktu podczas łączenia ('merge') i musi zadecydować, którą ze zmian przyjąć, ewentualnie ponownie zrewidować całą linijkę. -Mogą wystąpić dużo bardziej skomplikowane sytuacje. Systemy kontroli wersji potrafią poradzić sobie z prostymi przypadkami a te trudniejsze pozostawiają ludziom. Zazwyczaj sposób ich zachowania można skonfigurować. +Mogą wystąpić dużo bardziej skomplikowane sytuacje. Systemy kontroli wersji potrafią poradzić sobie z prostymi przypadkami, a te trudniejsze pozostawiają ludziom. Zazwyczaj sposób ich zachowania można skonfigurować. diff --git a/pl/multiplayer.txt b/pl/multiplayer.txt index 2836b396..c90b9ca6 100644 --- a/pl/multiplayer.txt +++ b/pl/multiplayer.txt @@ -1,6 +1,6 @@ == Multiplayer Git == -Na początku zastosowałem Git w prywatnym projekcie, gdzie byłem jedynym programistą. Z poleceń, w związku z rozproszoną naturą Gita, potrzebowałem jedynie komende *pull* i *clone*, dzięki czemu mogłem trzymać ten sam projekt w kilku miejscach. +Na początku zastosowałem Git w prywatnym projekcie, gdzie byłem jedynym programistą. Z poleceń, w związku z rozproszoną naturą Gita, potrzebowałem jedynie komendę *pull* i *clone*, dzięki czemu mogłem trzymać ten sam projekt w kilku miejscach. Później chciałem opublikować mój kod za pomocą Gita i dołączyć zmiany kolegów. Musiałem nauczyć się zarządzać projektami, nad którymi zaangażowani byli programiści z całego świata. Na szczęście jest to silną stroną Gita i chyba jego racją bytu. @@ -11,7 +11,7 @@ Każdy 'commit' otrzymuje nazwę i adres e-mail autora, które zostaną pokazane $ git config --global user.name "Jan Kowalski" $ git config --global user.email jan.kowalski@example.com -Jeśli opóścisz przełącznik '--global' zmiany zostaną zastosowane wyłącznie do aktualnego repozytorium. +Jeśli opuścisz przełącznik '--global' zmiany zostaną zastosowane wyłącznie do aktualnego repozytorium. === Git przez SSH, HTTP === @@ -64,7 +64,7 @@ a nowy 'bundle' tworzymy następnie poprzez: === Patches: globalny środek płatniczy === -'Patches' to jawne zobrazowanie twoich zmian, które mogą być jednocześnie rozumiane przez komputer i człowieka. Dodaje im to uniwersalnej mocy przyciągania. Możesz wysłać patch prowadzącym projekt, niezależnie od tego, jakiego używają systemu kontroli wersji. Doputy twoi współpracownicy potrafią czytać swoje maile, mogą widzieć również twoje zmiany. Również i z twojej strony wszystko, czego ci potrzeba to funkcjonujące konto e-mailowe: nie istnieje konieczność zakładania repozytorium online. +'Patches' to jawne zobrazowanie twoich zmian, które mogą być jednocześnie rozumiane przez komputer i człowieka. Dodaje im to uniwersalnej mocy przyciągania. Możesz wysłać patch prowadzącym projekt, niezależnie od tego, jakiego używają systemu kontroli wersji. Dopóty twoi współpracownicy potrafią czytać swoje maile, mogą widzieć również twoje zmiany. Również i z twojej strony wszystko, czego ci potrzeba to funkcjonujące konto e-mailowe: nie istnieje konieczność zakładania repozytorium online. Przypomnij sobie pierwszy rozdział: @@ -92,7 +92,7 @@ Patch zostanie wprowadzony i utworzy commit, włącznie z informacjami jak na pr Jeśli stosujesz webmail musisz ewentualnie poszukać opcji pokazania treści w formie niesformatowanego textu, zanim zapamiętasz patch do pliku. -Występują minimalne różnice między aplikacjami e-mailowymi bazującymi na mbox, ale jeśli korzystasz z takiej, należysz do grupy ludzi, która za pewne umie się z nimi obchodzić bez czytania instrukcji! +Występują minimalne różnice między aplikacjami e-mailowymi bazującymi na mbox, ale jeśli korzystasz z takiej, należysz do grupy ludzi, która zapewne umie się z nimi obchodzić bez czytania instrukcji! === Przepraszamy, przeprowadziliśmy się === @@ -160,7 +160,7 @@ Sprawdź *git help remote* by zobaczyć, jak usuwa się repozytoria, ignoruje pe W moich projektach preferuję, gdy pomagający mi programiści przygotują własne repozytoria z których mogę wykonać 'pull'. Większość hosterów Gita pozwala na utworzenie jednym kliknięciem twojego własnego forka innego projektu. -Gdy przywołałem moją gałęź korzystam z poleceń Gita dla nawigacji i kontroli zmian, które najlepiej, gdy są dobrze zorganizowane i udokumentowane. Wykonuję 'merge' moich własnych zmian i przeprowadzam ewentualnie dalsze zmiany. Gdy już jestem zadowolony, 'push' do zentralnego repozytorium. +Gdy przywołałem moją gałęź korzystam z poleceń Gita dla nawigacji i kontroli zmian, które najlepiej, gdy są dobrze zorganizowane i udokumentowane. Wykonuję 'merge' moich własnych zmian i przeprowadzam ewentualnie dalsze zmiany. Gdy już jestem zadowolony, 'push' do centralnego repozytorium. Mimo, iż dość rzadko otrzymuję posty, jestem zdania, że ta metoda się opłaca. Zobacz http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[Post na Blogu Linusa Torvalds (po angielsku)]. diff --git a/pl/preface.txt b/pl/preface.txt index 8b0f1396..0560761d 100644 --- a/pl/preface.txt +++ b/pl/preface.txt @@ -13,7 +13,7 @@ Zamiast wchodzić w szczegóły, oferujemy proste instrukcje dla osiągnięcia z .Tłumaczenia - link:/\~blynn/gitmagic/intl/zh_cn/[Chiński uproszczony]: od JunJie, Meng i JiangWei. Konwertacja do link:/~blynn/gitmagic/intl/zh_tw/[Tradycjonalnego chińskiego] za pomocą +cconv -f UTF8-CN -t UTF8-TW+. - - link:/~blynn/gitmagic/intl/fr/[Francuski]: od Alexandre Garel, Paul Gaborit, i Nicolas Deram. Również hostowany na http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[Francuski]: od Alexandre Garel, Paul Gaborit, i Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[Niemiecki]: od Benjamin Bellee i Armin Stebich; również hostowany na http://gitmagic.lordofbikes.de/[stronie Armina]. - http://www.slideshare.net/slide_user/magia-git[Portugalski]: od Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[wersja ODT]]. - link:/~blynn/gitmagic/intl/ru/[Rosyjski]: od Tikhon Tarnavsky, Mikhail Dymskov, i innych. @@ -31,7 +31,7 @@ Zamiast wchodzić w szczegóły, oferujemy proste instrukcje dla osiągnięcia z === Podziękowania! === -Jestem mile zaskoczony, że tak dużo ludzi pracowało nad przetłumaczeniem tych stron. Bardzo cenię, iż dzięki staraniom wyżej wspommnianych osób otrzymałem możliwość dotarcia do większego grona czytelników. +Jestem mile zaskoczony, że tak dużo ludzi pracowało nad przetłumaczeniem tych stron. Bardzo cenię, iż dzięki staraniom wyżej wspomnianych osób otrzymałem możliwość dotarcia do większego grona czytelników. Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, Joe Malin, i Tyler Breisacher przyczynilli się do poprawek i korektur. @@ -55,4 +55,4 @@ albo z serwerów lustrzanych: $ git clone git://git.assembla.com/gitmagic.git $ git clone git@bitbucket.org:blynn/gitmagic.git -GitHub, Assembla, i Bitbucket pozwalają na prowadzienie prywatnych repozytorii, te dwa ostatnie za darmo. +GitHub, Assembla, i Bitbucket pozwalają na prowadzenie prywatnych repozytoriów, te dwa ostatnie za darmo. diff --git a/pl/secrets.txt b/pl/secrets.txt index 4e9b155d..fb6a3833 100644 --- a/pl/secrets.txt +++ b/pl/secrets.txt @@ -1,6 +1,6 @@ == Uchylenie tajemnicy == -Rzućmy spojrzenie pod maskę silnika i wytłumaczymy w jaki sposób Git realizuje swoje cuda. Nie będę wchodził w szczegóły. Dla pogłębienia tematu odsyłam na http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[anielskojęzychny podręcznik użytkownika]. +Rzućmy spojrzenie pod maskę silnika i wytłumaczymy w jaki sposób Git realizuje swoje cuda. Nie będę wchodził w szczegóły. Dla pogłębienia tematu odsyłam na http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[angielskojęzyczny podręcznik użytkownika]. === Niewidzialność === @@ -16,7 +16,7 @@ Z kryptografią przez większość ludzi łączona jest poufność informacji, j Klucz hashujący SHA1 mogłabyś wyobrazić sobie jako składający się ze 160 bitów numer identyfikacyjny jednoznacznie opisujący dowolny łańcuch znaków, i który spotkasz w sowim życiu jeden jedyny raz. Nawet i więcej niż to: wszystkie łańcuchy znaków, jakie ludzkość przez wiele generacji stworzyła. -Sama suma konreolna SHA1 też jest łańcuchem znaków w formie bajtów. Możemy generować hashe SHA1 z łańcuchów samych zawierających inne hashe SHA1. Ta prosta obserwacja okazała się niesamowicie pożyteczna: jeśli cię to zainteresowało poszukaj informacji na temat 'hash chains'. Zobaczymy później w jaki sposób wykorzystuje je Git dla zapewnienia produktywności i integralności danych. +Sama suma kontrolna SHA1 też jest łańcuchem znaków w formie bajtów. Możemy generować hashe SHA1 z łańcuchów samych zawierających inne hashe SHA1. Ta prosta obserwacja okazała się niesamowicie pożyteczna: jeśli cię to zainteresowało poszukaj informacji na temat 'hash chains'. Zobaczymy później w jaki sposób wykorzystuje je Git dla zapewnienia produktywności i integralności danych. Krótko mówiąc, Git przechowuje twoje dane w podkatalogu `.git/objects`, gdzie zamiast nazw plików znajdziesz numery identyfikacyjne. Poprzez wykorzystanie tych numerów identyfikacyjnych jako nazwy plików razem z kilkoma innymi trikami związanymi z plikami blokującymi i znacznikami czasu, Git zamienia twój prosty system plików na produktywną i solidną bazę danych. @@ -134,13 +134,13 @@ To jest pierwszy 'commit', przez to nie posiada matczynych 'commits'. Następuj === Nie do odróżnienia od magii === -Tajemnice Gita wydają się być proste. Wygląda to jak połączenie kilku skryptów, troszeczkę kodu C i w przeciągu kilku godzin jesteśmy gotowi: zmiksowanie podstawowych operacji na systemie danych, obliczenia SHA1, przyprawienie plikami blokującymy i synchronizacją dla stabilności. W sumie można by tak opisać najwcześniejsze wersje Gita. Tym niemniej, abstrahując od udanych trików pakujących, by oszczędnie odnosić się z pamięcią i udanych trików indeksujących by zaoszczędzić czas, wiemy jak Git sprawnie przemienia system danych w objektową bazę danych, co jest optymalne dla kontroli wersji. +Tajemnice Gita wydają się być proste. Wygląda to jak połączenie kilku skryptów, troszeczkę kodu C i w ciągu kilku godzin jesteśmy gotowi: zmiksowanie podstawowych operacji na systemie danych, obliczenia SHA1, przyprawienie plikami blokującymy i synchronizacją dla stabilności. W sumie można by tak opisać najwcześniejsze wersje Gita. Tym niemniej, abstrahując od udanych trików pakujących, by oszczędnie odnosić się z pamięcią i udanych trików indeksujących by zaoszczędzić czas, wiemy jak Git sprawnie przemienia system danych w objektową bazę danych, co jest optymalne dla kontroli wersji. Przyjmijmy, gdy jakikolwiek plik w obiektowej bazie danych ulegnie zniszczeniu poprzez błąd nośnika, to jego SHA1 nie będzie zgadzać się z jego zawartością, co od razu wskaże nam problem. Poprzez tworzenie kluczy SHA1 z kluczy SHA1 innych objektów, osiągniemy integralność danych na wszystkich poziomach. 'Commits' są elementarne, to znaczy, 'commit' nie potrafi zapamiętać jedynie części zmian: hash SHA1 'commit' możemy obliczyć i zapamiętać dopiero po tym gdy zapamiętane zostały wszystkie obiekty 'tree', 'blob' i rodziców 'commit'. Obiektowa baza dynch jest odporna na nieoczekiwane przerwy, jak na przykład przerwanie dostawy prądu. Możemy przetrwać nawet podstępnego przeciwnika. Wyobraź sobie, ktoś ma zamiar zmienić treść jakiegoś pliku, która leży w jakiejś starszej wersji projektu. By sprawić pozory, że baza danych wygląda nienaruszona musiałby zmienić sumy kontrolne SHA1 korespondujących obiektów, ponieważ plik zawiera teraz zmieniony sznur znaków. To znaczy również, że musiałby zmienić każdy hash obiektu 'tree', które ją referują oraz w wyniku tego wszystkie sumy kontrolne 'commits' zawierające obiekty 'tree' dodatkowo do pochodnych tych 'commits'. Oznacza to również, że suma kontrolna oficjalnego HEAD różni się od sumy kontrolnej HEAD manipulowanego repozytorium. Wystarczy teraz prześledzić ścieżkę różniących się hashy SHA1, odnaleźć okaleczony plik, jak i 'commit' w którym po raz pierwszy wystąpił. -Krótko mówiąc, dopuki reprezentujące ostatni commit 20 bajtów są zabezpieczone, sfałszowanie repozytorium Gita nie jest możliwe. +Krótko mówiąc, dopóki reprezentujące ostatni commit 20 bajtów są zabezpieczone, sfałszowanie repozytorium Gita nie jest możliwe. A co ze sławnymi możliwościami Gita? 'Branching'? 'Merging'? 'Tags'? To szczegół. Aktualny HEAD przetrzymywany jest w pliku +.git/HEAD+, która posiada hash SHA1 ostatniego 'commit'. Hash SHA1 zostaje aktualizowany podczas wykonania 'commit', tak samo jak i przy wielu innych poleceniach. 'branches' to prawie to samo, są plikami zapamiętanymi w +.git/refs/heads+. 'Tags' również, znajdziemy je w +.git/refs/tags+, są one jednak aktualizowane poprzez serię innych poleceń. diff --git a/pl/translate.txt b/pl/translate.txt index c658ee47..1f1044ba 100644 --- a/pl/translate.txt +++ b/pl/translate.txt @@ -1,8 +1,8 @@ == Załącznik B: Przetłumaczyć to HOWTO == -Aby przetłumaczyć moje HOWTO polecam wykonanie następujących poniżej kroków, wtedy moje skrypty będą w prosty sposób mogły wygenerować wersje HTML i PDF. Poza tym wszystkie tłumaszenia mogą być prowadzone w jednym repozytorium. +Aby przetłumaczyć moje HOWTO polecam wykonanie następujących poniżej kroków, wtedy moje skrypty będą w prosty sposób mogły wygenerować wersje HTML i PDF. Poza tym wszystkie tłumaczenia mogą być prowadzone w jednym repozytorium. -Sklonuj texty źródłowe, następnie utwórz katalog o nazwie skrótu IETF przetłumaszonego języka: sprawdź http://www.w3.org/International/articles/language-tags/Overview.en.php[Artykół W3C o internacjonalizacji]. Na przykład, angielski to "en", a japoński to "ja". Skopiuj wszystkie pliki +txt+ z katalogu "en" do nowoutworzonego katalogu. +Sklonuj teksty źródłowe, następnie utwórz katalog o nazwie skrótu IETF przetłumaczonego języka: sprawdź http://www.w3.org/International/articles/language-tags/Overview.en.php[Artykuł W3C o internacjonalizacji]. Na przykład, angielski to "en", a japoński to "ja". Skopiuj wszystkie pliki +txt+ z katalogu "en" do nowo utworzonego katalogu. Aby przykładowo przetłumaczyć to HOWTO na http://de.wikipedia.org/wiki/Klingonische_Sprache[Klingonisch], musisz wykonać następujące polecenia: @@ -18,4 +18,4 @@ Edytuj Makefile i dodaj skrót języka do zmiennej `TRANSLATIONS`. Teraz możesz $ make tlh $ firefox book-tlh/index.html -Używaj często 'commit' a gdy już skończysz, to daj znać. GitHub posiada interfejs, który to ułatwi: utwórz twój własny 'Fork' projektu "gitmagic", 'push' twoje zmiany i daj mi znać, by je 'mergen'. +Używaj często 'commit' a gdy już skończysz, to daj znać. GitHub posiada interfejs, który to ułatwi: utwórz twój własny 'Fork' projektu "gitmagic", 'push' twoje zmiany i daj mi znać, by można było wykonać operację 'merge'. diff --git a/pt_br/drawbacks.txt b/pt_br/drawbacks.txt index c88d14af..705848c7 100644 --- a/pt_br/drawbacks.txt +++ b/pt_br/drawbacks.txt @@ -14,7 +14,7 @@ O Git no Microsoft Windows pode ser trabalhoso: - http://cygwin.com/[Cygwin], é um ambiente que deixa o Windows parecido com o Linux, tem http://cygwin.com/packages/git/[uma versão do Git para Windows]. -- http://code.google.com/p/msysgit/[Git no MSys] é uma alternativa que requer suporte minimo para execução, embora alguns poucos comandos precisem ser mais trabalhados. +- https://gitforwindows.org/[Git para Windows] é uma alternativa que requer suporte minimo para execução, embora alguns poucos comandos precisem ser mais trabalhados. === Arquivos Independentes === diff --git a/pt_br/preface.txt b/pt_br/preface.txt index e4ee9089..45204de1 100644 --- a/pt_br/preface.txt +++ b/pt_br/preface.txt @@ -13,7 +13,7 @@ Ao invés de entrar em detalhes, forneceremos apenas instruções para casos esp .Traduções - link:/\~blynn/gitmagic/intl/zh_cn/[Simplified Chinese]: by JunJie, Meng and JiangWei. Converted to link:/~blynn/gitmagic/intl/zh_tw/[Traditional Chinese] via +cconv -f UTF8-CN -t UTF8-TW+. - - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, and Nicolas Deram. Also hosted at http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel, Paul Gaborit, and Nicolas Deram. - link:/~blynn/gitmagic/intl/de/[German]: by Benjamin Bellee and Armin Stebich; also http://gitmagic.lordofbikes.de/[hosted on Armin's website]. - link:/~blynn/gitmagic/intl/pt-BR/[Portuguese-Brazilian]: by J.I.Serafini and Leonardo Siqueira Rodrigues. - link:/~blynn/gitmagic/intl/ru/[Russian]: by Tikhon Tarnavsky, Mikhail Dymskov, and others. diff --git a/ru/drawbacks.txt b/ru/drawbacks.txt index c0e95c85..914f2ca4 100644 --- a/ru/drawbacks.txt +++ b/ru/drawbacks.txt @@ -14,7 +14,7 @@ Git на Microsoft Windows может быть громоздким: - http://cygwin.com/[Cygwin], Linux-подобная среда для Windows, содержащая http://cygwin.com/packages/git/[порт Git на Windows]. -- http://code.google.com/p/msysgit/[Git на MSys], вариант, требующий минимальной рантайм поддержки, хотя некоторые комманды нуждаются в доработке. +- https://gitforwindows.org/[Git для Windows], вариант, требующий минимальной рантайм поддержки, хотя некоторые комманды нуждаются в доработке. === Несвязанные файлы === diff --git a/ru/preface.txt b/ru/preface.txt index 3feae48c..b34f865d 100644 --- a/ru/preface.txt +++ b/ru/preface.txt @@ -20,12 +20,12 @@ http://git.or.cz/[Git] это швейцарский нож управления .Переводы - - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[ Китайский (упрощенный)]: JunJie, Meng и JiangWei. + - link:/~blynn/gitmagic/intl/zh_cn/[Китайский (упрощенный)]: JunJie, Meng и JiangWei. - link:/~blynn/gitmagic/intl/es/[Испанский]: Rodrigo Toledo. - link:/~blynn/gitmagic/intl/de/[Немецкий]: Benjamin Bellee и Armin Stebich. Armin также разместил http://gitmagic.lordofbikes.de/[немецкий перевод на его сайте]. - link:/~blynn/gitmagic/intl/ru/[Русский]: Тихон Тарнавский, Михаил Дымсков и другие. - link:/~blynn/gitmagic/intl/uk/[Украинский]: Владимир Боденчук. - - link:/~blynn/gitmagic/intl/fr/[Французский]: Alexandre Garel. Также размещён на http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[Французский]: Alexandre Garel. - http://www.slideshare.net/slide_user/magia-git[Португальский]: Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[в формате ODT]]. .Другие варианты diff --git a/uk/drawbacks.txt b/uk/drawbacks.txt index 0930986d..5ea6a38c 100644 --- a/uk/drawbacks.txt +++ b/uk/drawbacks.txt @@ -14,7 +14,7 @@ Git на Microsoft Windows може бути громіздким: - http://cygwin.com/[Cygwin], Linux-подібне середовище для Windows, яке містить http://cygwin.com/packages/git/[порт Git на Windows]. -- http://code.google.com/p/msysgit/[Git на MSys], варіант, що вимагає мінімальної рантайм підтримки, хоча деякі команди потребують доопрацювання. +- https://gitforwindows.org/[Git для Windows], варіант, що вимагає мінімальної рантайм підтримки, хоча деякі команди потребують доопрацювання. === Незв'язані файли === diff --git a/uk/preface.txt b/uk/preface.txt index 8b14f9d5..489f2f48 100644 --- a/uk/preface.txt +++ b/uk/preface.txt @@ -14,12 +14,12 @@ http://git.or.cz/[Git] — це швейцарський ніж керуванн - link:/~blynn/gitmagic/intl/vi/[В'єтнамська]: Trần Ngọc Quân; також http://vnwildman.users.sourceforge.net/gitmagic/[розміщено на його вебсайті]. - link:/~blynn/gitmagic/intl/es/[Іспанська]: Rodrigo Toledo та Ariset Llerena Tapia. - - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[Китайська (спрощена)]: JunJie, Meng та JiangWei. Конвертовано у link:/~blynn/gitmagic/intl/zh_tw/[Традиційна китайська] via +cconv -f UTF8-CN -t UTF8-TW+. + - link:/\~blynn/gitmagic/intl/zh_cn/[Китайська (спрощена)]: JunJie, Meng та JiangWei. Конвертовано у link:/~blynn/gitmagic/intl/zh_tw/[Традиційна китайська] via +cconv -f UTF8-CN -t UTF8-TW+. - link:/~blynn/gitmagic/intl/de/[Німецька]: Benjamin Bellee і Armin Stebich. Armin також розмістив http://gitmagic.lordofbikes.de/[німецький переклад на своєму сайті]. - http://www.slideshare.net/slide_user/magia-git[Португальська]: Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[в форматі ODT]]. - link:/~blynn/gitmagic/intl/ru/[Російська]: Тихон Тарнавский, Михаил Дымсков і інші. - link:/~blynn/gitmagic/intl/uk/[Українська]: Володимир Боденчук. - - link:/~blynn/gitmagic/intl/fr/[Французька]: Alexandre Garel, Paul Gaborit, та Nicolas Deram. Також розміщений на http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[Французька]: Alexandre Garel, Paul Gaborit, та Nicolas Deram. .Інші варіанти diff --git a/vi/drawbacks.txt b/vi/drawbacks.txt index 8845032c..d9908bdb 100644 --- a/vi/drawbacks.txt +++ b/vi/drawbacks.txt @@ -17,7 +17,7 @@ Sử dụng Git trên hệ điều hành Microsoft Windows có vẻ hơi cồng - http://cygwin.com/[Cygwin], mô phỏng Linux dành cho Windows, có chứa http://cygwin.com/packages/git/[Git đã chuyển đổi để chạy trên Windows]. -- http://code.google.com/p/msysgit/[Git chạy trên MSys] là một thay thế với các hỗ trợ tối thiểu nhất, bởi vì chỉ cần một ít lệnh để thực hiện một số việc mà thôi. +- https://gitforwindows.org/[Git cho Windows] là một thay thế với các hỗ trợ tối thiểu nhất, bởi vì chỉ cần một ít lệnh để thực hiện một số việc mà thôi. === Các Tập tin Không liên quan === diff --git a/vi/preface.txt b/vi/preface.txt index 3661aabc..c77e5b62 100644 --- a/vi/preface.txt +++ b/vi/preface.txt @@ -13,7 +13,7 @@ Thay vì đi sâu vào chi tiết, chúng tôi đưa ra phác thảo cách làm .Bản dịch - link:/\~blynn/gitmagic/intl/zh_cn/[Tiếng Trung Giản thể]: dịch bởi JunJie, Meng và JiangWei. Đã chuyển đổi sang: link:/~blynn/gitmagic/intl/zh_tw/[Tiếng Trung Phồn thể] thông qua lệnh +cconv -f UTF8-CN -t UTF8-TW+. - - link:/~blynn/gitmagic/intl/fr/[Tiếng Pháp]: dịch bởi Alexandre Garel; và đồng thời được xuất bản tại http://tutoriels.itaapy.com/[itaapy]. + - link:/~blynn/gitmagic/intl/fr/[Tiếng Pháp]: dịch bởi Alexandre Garel. - link:/~blynn/gitmagic/intl/de/[Tiếng Đức]: dịch bởi Benjamin Bellee và Armin Stebich; và đồng thời xuất bản http://gitmagic.lordofbikes.de/[trên website của Armin]. - link:/~blynn/gitmagic/intl/it/[Tiếng Ý]: dịch bởi Mattia Rigotti. - link:/~blynn/gitmagic/intl/ko/[Tiếng Hàn Quốc]: dịch bởi Jung-Ho (John) Han; đồng thời https://sites.google.com/site/drinkhanjohn/useful-links/[xuất bản trên trang web của John]. diff --git a/zh_cn/basic.txt b/zh_cn/basic.txt index c6c23560..5e207075 100644 --- a/zh_cn/basic.txt +++ b/zh_cn/basic.txt @@ -11,7 +11,7 @@ $ git add . $ git commit -m "My first backup" -现在如果你的编辑乱了套，恢复之前的版本： +现在如果你的编辑乱了套，恢复之前的版本可以使用： $ git reset --hard @@ -31,9 +31,9 @@ $ git rm kludge.h obsolete.c $ git rm -r incriminating/evidence/ -这些文件如果还没删除，Git删除它们。 +这些文件如果还没被从系统中删除，Git将会删除它们。 -重命名文件和先删除旧文件，再添加新文件的一样。也有一个快捷方式 *git mv* ，和 +重命名文件同删除旧文件，并同时添加新文件一样。也有一个快捷方式 *git mv* ，和 *mv* 命令的用法一样。例如： $ git mv bug.c feature.c @@ -41,11 +41,11 @@ === 进阶撤销/重做 === 有时候你只想把某个时间点之后的所有改动都回滚掉，因为这些的改动是不正确的。那 -么： +么使用这个命令： $ git log -来显示最近提交列表，以及他们的SHA1哈希值: +来显示最近提交列表，以及查看他们的SHA1哈希值: ---------------------------------- commit 766f9881690d240ba334153047649b8b8f11c664 @@ -61,13 +61,13 @@ Date: Thu Jan 1 00:00:00 1970 +0000 Initial commit. ---------------------------------- -哈希值的前几个字符足够确定一个提交；也可以拷贝粘贴完整的哈希值，键入： +哈希值的前几个字符足够确定一个提交；也可以拷贝粘贴完整的哈希值，输入： $ git reset --hard 766f 来恢复到一个指定的提交状态，并从记录里永久抹掉所有比该记录新一些的提交。 -另一些时候你想简单地跳到一个旧状态。这种情况，键入： +另一些时候你想简单地回朔到某一个旧状态。这种情况，键入： $ git checkout 82f5 @@ -91,15 +91,15 @@ Date: Thu Jan 1 00:00:00 1970 +0000 一轮的较新状态。你现在打的所有游戏记录会在你刚进入的、代表另一个真实的分支 里。<<branch,我们稍后论述>>。 -你可以选择只恢复特定文件和目录，通过将其加在命令之后： +你可以选择只恢复特定文件和目录，这将通过将其加在命令之后来实现： $ git checkout 82f5 some.file another.file -小心，这种形式的 *checkout* 会不声不响地覆盖文件。为阻止意外发生，在运行任何 +小心，这种形式的 *checkout* 会不声不响地覆盖当前文件。为防止意外发生，在运行任何 checkout命令之前做提交，尤其在初学Git的时候。通常，任何时候你觉得对运行某个命 令不放心，无论Git命令还是不是Git命令，就先运行一下 *git commit -a* 。 -不喜欢拷贝站题哈希值？那就用： +不喜欢拷贝旧提交的哈希值？那就用： $ git checkout :/"My first b" @@ -114,19 +114,21 @@ checkout命令之前做提交，尤其在初学Git的时候。通常，任何时 $ git commit -a $ git revert 1b6d -讲撤销给定哈希值的提交。本撤销被记录为一个新的提交，你可以通过运行 *git log* +将撤销给定哈希值的提交。本撤销被记录为一个新的提交，你可以通过运行 *git log* 来确认这一点。 === 变更日志生成 === -一些项目要求生成变更日志http://en.wikipedia.org/wiki/Changelog[changelog]. 生 -成一个，通过键入： +一些项目要求生成变更日志http://en.wikipedia.org/wiki/Changelog[changelog]. 若 +要生成一个变更日志，可以键入： $ git log > ChangeLog +来实现。 + === 下载文件 === -得到一个由Git管理的项目的拷贝，通过键入： +得到一个由Git管理的项目的拷贝，则键入： $ git clone git://server/path/to/files @@ -143,13 +145,13 @@ checkout命令之前做提交，尤其在初学Git的时候。通常，任何时 $ git pull - + === 快速发布 === 假设你写了一个脚本，想和他人分享。你可以只告诉他们从你的计算机下载，但如果此 -时你正在改进你的脚本，或加入试验性质的改动，他们下载了你的脚本，他们可能由此 -陷入困境。当然，这就是发布周期存在的原因。开发人员可能频繁进行项目修改，但他 -们只在他们觉得代码可以见人的时候才择时发布。 +时你正在改进你的脚本，或加入了试验性质的改动，他们下载了你的脚本，他们可能因 +此陷入困境。当然，这就是发布周期存在的原因。开发人员可能频繁进行项目修改，但 +他们只在他们觉得代码可以见人的时候才择时发布。 用Git来完成这项，需要进入你的脚本所在目录： @@ -170,12 +172,12 @@ checkout命令之前做提交，尤其在初学Git的时候。通常，任何时 $ git commit -a -m "Next release" -并且你的用户可以通过进入包含你脚本的目录，并键入下列命令，来更新他们的版本： +而你的用户则可以进入包含你脚本的目录，并键入下列命令，来更新他们的版本： $ git pull -你的用户永远也不会取到你不想让他们看到的脚本版本。显然这个技巧对所有的东西都 -是可以，不仅是对脚本。 +你的用户永远也不会取到你不想让他们看到的脚本版本。显然这个技巧对所有代码库都 +适用，而不仅仅局限于脚本。 === 我们已经做了什么？ === @@ -198,8 +200,8 @@ checkout命令之前做提交，尤其在初学Git的时候。通常，任何时 我也经常用http://sourceforge.net/projects/qgit[qgit] 浏览历史, 因为他的图形界 面很养眼，或者 http://jonas.nitro.dk/tig/[tig] ，一个文本界面的东西，很慢的网 -络状况下也工作的很好。也可以安装web 服务器，运行 *git instaweb* ，就可以用任 -何浏览器浏览了。 +络状况下也可以工作的很好。也可以安装web 服务器，运行 *git instaweb* ，就可以用 +任意浏览器浏览了。 === 练习 === @@ -208,7 +210,7 @@ checkout命令之前做提交，尤其在初学Git的时候。通常，任何时 至少有三个解决方案。假设我们在D： - 1. A与B的差别是那些删除的文件。我们可以创建一个补丁代表这些差别，然后吧补丁 + 1. A与B的差别是那些删除的文件。我们可以创建一个补丁代表这些差别，然后把补丁 打上： $ git diff B A | git apply diff --git a/zh_cn/branch.txt b/zh_cn/branch.txt index b7d2f9e6..f3f7b3f7 100644 --- a/zh_cn/branch.txt +++ b/zh_cn/branch.txt @@ -2,13 +2,13 @@ 即时分支合并是Git最给力的杀手锏。 -*问题* ：外部因素要求必须切换场景。在发布版本中突然蹦出个严重缺陷。某个特性完 -成的截至日期就要来临。在项目关键部分可以提供帮助的一个开发正打算离职。所有情 -况逼迫你停下所有手头工作，全力扑到到这个完全不同的任务上。 +*问题* ：外部因素要求必须切换场景。不如说，在发布版本中突然蹦出个严重缺陷；某 +个特性完成的截至日期就要来临；在项目关键部分可以提供帮助的一个开发正打算离 +职。所有情况逼迫你停下所有手头工作，全力扑到到这个完全不同的任务上。 -打断思维的连续性会使你的生产力大大降低，并且切换上下文也更麻烦，更大的损失。 -使用中心版本控制我们必须从中心服务器下载一个新的工作拷贝。分布式系统的情况就 -好多了，因为我们能够在本地克隆所需要的版本。 +打断思维的连续性会使你的生产力大大降低，并且切换上下文越麻烦，潜在的损失也越 +大。如果使用中心版本控制，我们就必须从中心服务器下载一个新的工作拷贝。分布式 +系统的情况就好多了，因为我们能够在本地克隆所需要的版本。 但是克隆仍然需要拷贝整个工作目录，还有直到给定点的整个历史记录。尽管Git使用文 件共享和硬链接减少了花费，项目文件自身还是必须在新的工作目录里重建。 @@ -32,7 +32,7 @@ $ git add . $ git commit -m "Initial commit" -我们已经创建了一个Git仓库，该仓库记录一个包含特定信息的文件。现在我们键入： +我们已经创建了一个Git仓库，该仓库保存了一个包含特定信息的文件。现在我们键入： $ git checkout -b boss # 之后似乎没啥变化 $ echo "My boss is smarter than me" > myfile.txt @@ -129,7 +129,7 @@ === 不间断工作流 === 经常在硬件项目里，计划的第二步必须等第一步完成才能开始。待修的汽车傻等在车库 -里，直到特定的零件从工厂运来。一个原型在其可以构建之前，可能苦等芯片成型。 +里，直到特定的零件从工厂运来。一个原型在其可以构建之前，可能要苦等芯片成型。 软件项目可能也类似。新功能的第二部分不得不等待，直到第一部分发布并通过测试。 一些项目要求你的代码需要审批才能接受，因此你可能需要等待第一部分得到批准，才 @@ -166,8 +166,8 @@ $ git branch master HEAD~7 # 以七次前提交建一个新的“master”。 分支 `master` 只有第一部分内容，其他内容在分支 `part2` 。 我们现在后一个分支； -我们创建了 `master` 分支还没有切换过去，因为我们想继续工作在 `part2` 。这是不 -寻常的。直到现在，我们已经在创建之后切换到分支，如： +我们创建了 `master` 分支还没有切换过去，因为我们想继续在分支 `part2` 上工作。这 +是不寻常的。直到现在，我们已经在创建之后切换到分支，如： $ git checkout HEAD~7 -b master # 创建分支，并切换过去。 @@ -232,5 +232,5 @@ 格的用户。一些用户喜欢只保持一个打开的窗口，然后用标签浏览多个网页。一些可能 坚持另一个极端：任何地方都没有标签的多窗口。一些喜好处在两者之间。 -分支类似你工作目录的标签，克隆类似打开的浏览器新窗口。这些是本地操作很快，那 -为什么不试着找出最适合你的组合呢？Git让你按你确实所希望的那样工作。 +分支类似于你工作目录的标签，克隆则类似于打开的浏览器新窗口。这些是本地操作很 +快，那为什么不试着找出最适合你的组合呢？Git让你按你确实所希望的那样工作。 diff --git a/zh_cn/clone.txt b/zh_cn/clone.txt index 1bcfece6..a45172ca 100644 --- a/zh_cn/clone.txt +++ b/zh_cn/clone.txt @@ -1,4 +1,4 @@ -== 克隆周边 == +== 克隆代码库 == 在较老一代的版本控制系统里，checkout是获取文件的标准操作。你将获得一组特定保 存状态的文件。 @@ -43,12 +43,12 @@ $ git daemon --detach # 它也许已经在运行了 -对一些Git伺服服务，按照其指导来初始化空Git仓库。一般是在网页上填一个表单。 +对一些Git伺服服务，按照其提示来初始化空Git仓库。一般是在服务器网页上填写一个表单。 -把你的项目“推”到中心服务器： +把你的项目“推送”到中心服务器： $ git push central.server/path/to/proj.git HEAD -捡出源码，可以键入： +若要克隆源码，可以键入： $ git clone central.server/path/to/proj.git @@ -56,7 +56,7 @@ $ git commit -a -更新到最近版本： +更新到最新版本： $ git pull @@ -68,11 +68,11 @@ $ git push -如果主服务器由于其他开发的活动，有了新的变更，这个捡入会失败，该开发应该把最 -新版本拿下来，解决合并冲突，然后重试。 +如果主服务器由于其他开发的活动，有了新的变更，这个推送将会失败，开发者应该把最 +新版本更新至本地机器，解决合并冲突，然后重试。 -为使用上面pull和push命令，开发必须有SSH访问权限。不过，通过键入以下命令，任何 -人都可以看到源码： +为使用上面的pull和push命令，开发者必须有SSH访问权限。不过，通过键入以下命令，任 +何人都可以看到源码： $ git clone git://central.server/path/to/proj.git @@ -81,8 +81,8 @@ git协议禁止推操作。 === 封闭源码 === -闭源项目不要执行touch命令，并确保你从未创建`git-daemon-export-ok`文件。资源库 -不再可以通过git协议获取；只有那些有SSH访问权限的人才能看到。如果你所有的资源 +闭源项目须避免执行touch命令，并确保你从未创建`git-daemon-export-ok`文件。资源 +库不再可以通过git协议获取；只有那些有SSH访问权限的人才能看到。如果你所有的资源 库都是封闭的，那也没必要运行运行git守护了，因为所有沟通都走SSH。 === 裸仓库 === @@ -91,8 +91,9 @@ git协议禁止推操作。 的文件。换句话说，它维护项目历史，而且从不保存任何给定版本的快照。 裸仓库扮演的角色和中心版本控制系统中中心服务器的角色类似：你项目的中心。开 -发从其中克隆项目，捡入新近改动。典型地裸仓库存在一个服务器上，该服务器除了 -分散数据外并不做啥。开发活动发生在克隆上，因此中心仓库没有工作目录也行。 +发从其中克隆项目，检入新近改动。典型地裸仓库存在一个服务器上，该服务器除了 +分散数据外并不担负额外的任务。开发活动发生在克隆的代码库上，因此中心仓库没 +有工作目录也行。 很多Git命令在裸仓库上失败，除非指定仓库路径到环境变量`GIT_DIR`，或者指定 @@ -108,7 +109,7 @@ shell访问怎么办呢？ 然而，除了这个案例，我们反对推进仓库，因为当目标有工作目录时，困惑随之而来。 -简短截说，学习Git的时候，只在目标是裸仓库的时候push，否则用pull的方式。 +简短来说，学习Git的时候，只在目标是裸仓库的时候使用push，否则用pull的方式。 === 项目分叉 === @@ -124,12 +125,12 @@ shell访问怎么办呢？ === 终极备份 === -会有很多散布在各处，禁止篡改的冗余存档吗? 如果你的项目有很多开发，那干脆啥也 -别做了。你的每份代码克隆是一个有效备份。不仅当前状态，还包括你项目整个历史。 -感谢哈希加密算法，如果任何人的克隆被损坏，只要他们与其他的交互，这个克隆就会 -被修好。 +需要制作很多散布在各处，并禁止篡改的冗余存档吗? 如果你的项目有很多开发者参 +与，那你并不需要再做什么了。每份代码克隆都是一个有效备份。它不仅包含当前代码 +库状态，也同时包含了项目的整个历史。多谢哈希加密算法，如果任何人的克隆库被损 +坏，只要其与其他克隆库交互，损坏的代码就会被显示出来。 -如果你的项目并不是那么流行，那就找尽可能多的伺服来放克隆吧。 +如果你的项目并不是那么流行，那就找尽可能多的伺服来存放克隆库吧。 真正的偏执狂应该总是把HEAD最近20字节的SHA1哈希值写到安全的地方。应该保证安全， 而不是把它藏起来。比如，把它发布到报纸上就不错，因为对攻击者而言，更改每份报 @@ -201,25 +202,25 @@ Mercurial是一个类似的的版本控制系统，几乎可以和Git一起无 Git项目以适应Git用户，然而感谢`hg-git`插件，一个Git项目自动地适应Mercurial用 户。 -尽管该插件可以把一个Mercurial仓库转成一个Git仓库，通过推到一个空的仓库， -这个差事交给`hg-fast-export.sh`脚本还是更容易些。来自： +尽管该插件可以把一个Mercurial仓库转成一个Git仓库，通过推送一个空仓库来实现， +这个差事交给`hg-fast-export.sh`脚本来做还是更容易些。这个脚本来自： $ git clone git://repo.or.cz/fast-export.git -要转化，只需在一个空目录运行： +如需转化，只需在一个空目录运行： $ git init $ hg-fast-export.sh -r /hg/repo -注意该脚本应加入你的`$PATH`。 +注意，需要先将该脚本加入你的`$PATH`路径中，再执行以上命令行。 === Bazaar === 我们简略提一下Bazaar，它毕竟是紧跟Git和Mercurial之后最流行的自由分布式版本控 制系统。 -Bazaar有后来者的优势，它相对年轻些；它的设计者可以从前人的错误中学习，并且躲 -过去翻历史上犯过的错误。另外，它的开发人员对可移植性以及和与其它版本控制系统 +Bazaar有后来者的优势，它相对年轻些；它的设计者可以从前人的错误中学习，并且避免 +先行者在历史上犯过的错误。另外，它的开发人员对可移植性以及和与其它版本控制系统 的互操作性也考虑周全。 一个`bzr-git`插件让Bazaar用户在一定程度下可以工作在Git仓库。`tailor`程序转 @@ -229,14 +230,14 @@ Bazaar有后来者的优势，它相对年轻些；它的设计者可以从前 === 我偏爱Git的原因 === 我起先选择Git是因为我听说它能管理不可想象地不可管理的Linux内核源码。我从来没 -觉得有离开的必要。Git已经服侍的很好了，并且我也没有被其瑕疵所困扰。因为我主要 +觉得有离开的必要。Git已经工作的很好了，并且我也没有被其瑕疵所困扰。因为我主要 使用Linux，其他平台上的问题与我无关。 -还有，我偏爱C程序和bash脚本，以及诸如Python的可执行可脚本：较少依赖，并且我也 -沉迷于快速的执行时间。 +还有，我偏爱C程序和bash脚本，以及诸如Python的可执行可脚本：其代码依赖性较低，并 +且我也沉迷于快速的执行时间。 -我考虑过Git才能如何提高，甚至自己写类似的工具，但只作为研究练练手。即使完成这 -个项目，我也无论如何会继续使用Git，因为使用一个古里古怪的系统所获甚微。 +我考虑过Git如何才能提高，甚至自己写过类似的工具，但只作为学术研究练练手。即使我 +会完成这个项目，我也无论如何会继续使用Git，因为使用一个古里古怪的系统所获甚微。 -自然地，你的需求和期望可能不同，并且你可能使用另一个系统会好些。尽管如此，使 -用Git你都错不太远。 +自然地，你的需求和期望可能不同，并且你可能感觉使用另一个系统会好些。即便如此，使 +用Git你都不至于错太远。 diff --git a/zh_cn/drawbacks.txt b/zh_cn/drawbacks.txt index 632df2d8..ccc70d9d 100644 --- a/zh_cn/drawbacks.txt +++ b/zh_cn/drawbacks.txt @@ -1,49 +1,50 @@ == 附录 A: Git的缺点 == 有一些Git的问题，我已经藏在毯子下面了。有些可以通过脚本或回调方法轻易地解决， -有些需要重组或重定义项目，少数剩下的烦恼，还只能等待。或者更好地，投入进来帮 -忙。 +有些需要重组或重定义项目，少数剩下的烦恼，还只能等待。或者更好地，你可以加入 +Git项目来帮忙。 === SHA1 的弱点 === -随着时间的推移，密码学家发现越来越多的SHA1的弱点。已经发现对对资源雄厚的组织 -哈希冲撞是可能的。在几年内，或许甚至一个一般的PC也将有足够计算能力悄悄摧毁一 -个Git仓库。 +随着时间的推移，密码学家发现越来越多的SHA1的弱点。人们发现，对资源雄厚的组织 +而言，找到哈希冲突是可能的。在几年内，或许甚至一个一般的PC也将有足够计算能力 +悄悄摧毁一个Git仓库。 -希望在进一步研究摧毁SHA1之前，Git能迁移到一个更好的哈希算法。 +希望在进一步研究出摧毁SHA1的方法之前，Git能迁移到一个更好的哈希算法。 === 微软 Windows === Git在微软Windows上可能有些繁琐： -- http://cygwin.com/[Cygwin] ，, 一个Windows下的类Linux的环境，包含一个 http://cygwin.com/packages/git/[ 一个Git在Windows下的移植]. +- http://cygwin.com/[Cygwin] , 这是一个Windows下的类Linux的环境，其包含一 + 个 http://cygwin.com/packages/git/[一个Git在Windows下的移植]. + +- http://code.google.com/p/msysgit/[基于MSys的Git] 是另一个，要求最小运行 + 时支持，不过一些命令不能马上工作。 -- http://code.google.com/p/msysgit/[基于MSys的Git] 是另一个，要求最小运行时支持，不过一些命令不能马上工作。 - === 不相关的文件 === -如果你的项目非常大，包含很多不相关的文件，而且正在不断改变，Git可能比其他系统 -更不管用，因为独立的文件是不被跟踪的。Git跟踪整个项目的变更，这通常才是有益的。 +如果你的项目非常大，包含很多不相关的文件，而且目录树在不断变更，Git可能比其他系统 +更不可靠，因为独立的文件是不被跟踪的。Git跟踪整个项目的变更，这通常才是有益的。 一个方案是将你的项目拆成小块，每个都由相关文件组成。如果你仍然希望在同一个资 源库里保存所有内容的话，可以使用 *git submodule* 。 === 谁在编辑什么？ === -一些版本控制系统在编辑前强迫你显示地用某个方法标记一个文件。尽管这种要求很烦 -人，尤其是需要和中心服务器通讯时，不过它还是有以下两个好处的： +一些版本控制系统在编辑前会强迫你显示和用某个方法标记一个文件。尽管这种要求很烦 +人，尤其是需要和中心服务器通讯时。不过它还是有以下两个好处的： - 1. 比较速度快，因为只有被标记的文件需要检查。 + 1. 速度比较快，因为只有被标记的文件需要检查。 - 2. 可以知道谁在这个文件上工作，通过查询在中心服务器谁把这个文件标记为编辑状 - 态。 + 2. 通过查询在中心服务器谁把这个文件标记为编辑状态，可以知道谁正在这个文件上工作。 -使用适当的脚本，你也可以使Git达到同样的效果。这要求程序员协同工作，当他编辑一 +使用适当的脚本，你也可以使Git达到同样的效果。但这要求程序员协同工作，当他编辑一 个文件的时候还要运行特定的脚本。 === 文件历史 === -因为Git记录的是项目范围的变更，重造单一文件的变更历史比其他跟踪单一文件的版本 +因为Git记录的是项目范围内的变更，重造单一文件的变更历史比其他跟踪单一文件的版本 控制系统要稍微麻烦些。 好在麻烦还不大，也是值得的，因为Git其他的操作难以置信地高效。例如，`git @@ -52,33 +53,23 @@ checkout`比`cp -a`都快，而且项目范围的delta压缩也比基于文件 === 初始克隆 === -The initial cost is worth paying in the long run, as most future operations will then be fast and offline. However, in some situations, it may be preferable to create a shallow clone with the `--depth` option. This is much faster, but the resulting clone has reduced functionality. - 当一个项目历史很长后，与在其他版本系统里的检出代码相比，创建一个克隆的开销会 大的多。 长远来看，开始付出的代价还是值得付出的，因为大多将来的操作将由此变得很快，并 -可以离线完成。然而，在一些情况下，使用`--depth`创建一个浅克隆比较划算些。这种 +可以离线完成。然而，在一些情况下，使用`--depth`创建一个浅层克隆比较划算些。这种 克隆初始化的更快，但得到克隆的功能有所削减。 === 不稳定的项目 === -变更的大小决定写入的速度快慢是Git的设计。一般人做了小的改动就会提交新版本。这 -里一行臭虫修改，那里一个新功能，修改掉的注释等等。但如果你的文件在相邻版本之 -间存在极大的差异，那每次提交时，你的历史记录会以整个项目的大小增长。 - - - - - - - - +由变更的大小来决定写入的速度快慢是Git的特性。一般人做了小的改动就会提交新版 +本：这里修正一行错误，那里加一个新功能，或者修改注释等等。但如果你的文件在相邻 +版本之间存在极大的差异，那每次提交时，你的历史记录会随整个项目的大小增长。 -任何版本控制系统对此都束手无策，但标准的Git用户将遭受更多，因为一般来说，历史 -记录也会被克隆。 +任何版本控制系统对此都束手无策，但普通的Git用户将面对更多资源的消耗，因为一般 +来说，历史记录也会被克隆。 -应该检查一下变更巨大的原因。或许文件格式需要改变一下。小修改应该仅仅导致几个 +应该检查一下变更巨大的原因：或许文件格式需要改变一下。小修改应该仅仅导致几个 文件的细小改动。 或许，数据库或备份/打包方案才是正选，而不是版本控制系统。例如，版本控制就不适 @@ -89,26 +80,29 @@ The initial cost is worth paying in the long run, as most future operations will Git工具就不能用了，并且修复必须以补丁的形式提交。这也许还不错，因为似乎没人需 要大幅度变化的不稳定文件历史。 -另一个例子是基于固件的项目，使用巨大的二进制文件形式。用户对固件文件的变化历 -史没有兴趣，更新的压缩比很低，因此固件修订将使仓库无谓的变大。 +另一个例子是基于固件的项目，因为要用到巨大的二进制文件形式。用户对固件文件的变 +化历史没有兴趣，更新的压缩比很低，因此固件修订将使仓库无谓的变大。 -这种情况，源码应该保存在一个Git仓库里，二进制文件应该单独保存。为了简化问题， -应该发布一个脚本，使用Git克隆源码，对固件只做同步或Git浅克隆。 +这种情况下，源码应该保存在一个Git仓库里，但二进制文件应该单独保存。为了简化问题， +应该发布一个脚本，使用Git克隆源码，并对固件只做同步或Git浅层克隆。 === 全局计数器 === -一些中心版本控制系统维护一个正整数，当一个新提交被接受的时候这个整数就增长。Git则是通过哈希值来记录所有变更，这在大多数情况下都工作的不错。 +一些中心版本控制系统都会维护一个正整数，当一个新提交被接受的时候这个整数就增 +长。Git则是通过哈希值来记录所有变更，这在大多数情况下都工作的不错。 -但一些人喜欢使用整数的方法。幸运的是，很容易就可以写个脚本，这样每次更新，中心Git仓库就增大这个整数，或使用tag的方式，把最新提交的哈希值与这个整数关联起来。 +但一些人喜欢使用整数的方法。幸运的是，很容易就可以写个脚本，这样每次更新，中 +心Git仓库就增大这个整数，或使用tag的方式，把最新提交的哈希值与这个整数关联起来。 -每个克隆都可以维护这么个计数器，但这或许没什么用，因为只有中心仓库以及它的计数器对每个人才有意义。 +每个克隆都可以维护这么个计数器，但这或许没什么用，因为只有中心仓库以及它的计数器 +对每个人才有意义。 === 空子目录 === -空子目录不可加入管理。可以通过创建一个空文件以绕过这个问题。 +空子目录不可加入管理。但可以通过创建一个空文件以绕过这个问题。 Git的当前实现，而不是它的设计，是造成这个缺陷的原因。如果运气好，一旦Git得到 -更多关注，更多用户要求这个功能，这个功能就会被实现。 +更多关注，并其有更多用户要求这个功能，这个功能就会被实现。 === 初始提交 === @@ -125,7 +119,7 @@ Git将从定义零提交中受益：一旦一个仓库被创建起来，HEAD将 每个初始提交都隐式地成为这个零提交的后代。 不幸的是还有更糟糕的情况。如果把几个具有不同初始提交的分支合并到一起，之后的 -重新修订不可避免的需要人员的介入。 +重新修订不可避免的将需要人员的介入。 === 接口怪癖 === diff --git a/zh_cn/grandmaster.txt b/zh_cn/grandmaster.txt index ed144e3b..4803b8ba 100644 --- a/zh_cn/grandmaster.txt +++ b/zh_cn/grandmaster.txt @@ -1,25 +1,26 @@ == Git大师技 == 到现在，你应该有能力查阅 *git help* 页，并理解几乎所有东西。然而，查明解决特 -定问题需要的确切命令可能是乏味的。或许我可以省你点功夫：以下是我过去曾经需要 -的一些食谱。 +定问题需要的确切命令可能是乏味的。或许我可以省你点功夫：以下是我过去曾经用到 +的一些技巧。 === 源码发布 === -就我的项目而言，Git完全跟踪了我想打包并发布给用户的文件。创建一个源码包，我运 -行： +就我的项目而言，Git完全跟踪了我想打包并发布给用户的文件。如需创建一个源码包，我 +会运行： $ git archive --format=tar --prefix=proj-1.2.3/ HEAD === 提交变更 === -对特定项目而言，告诉Git你增加，删除和重命名了一些文件很麻烦。而键入如下命令会容易的多： +对特定项目而言，告诉Git你增加，删除和重命名了一些文件很麻烦。而键入如下命令会容易 +的多： $ git add . $ git add -u -Git将查找当前目录的文件并自己算出具体的情况。除了用第二个add命令，如果你也打 -算这时提交，可以运行`git commit -a`。关于如何指定应被忽略的文件，参见 *git +Git将查找当前目录的文件并计算出所有更改过的内容。除了第二个add命令，如果你也打 +算同时提交，则可以运行`git commit -a`。关于如何指定应被忽略的文件，参见 *git help ignore* 。 你也可以用一行命令完成以上任务： @@ -27,28 +28,28 @@ help ignore* 。 $ git ls-files -d -m -o -z | xargs -0 git update-index --add --remove 这里 *-z* 和 *-0* 选项可以消除包含特殊字符的文件名引起的不良副作用。注意这个 -命令也添加应被忽略的文件，这时你可能需要加上 `-x` 或 `-X` 选项。 +命令也会添加本应被忽略的文件，这时你可能需要加上 `-x` 或 `-X` 选项。 === 我的提交太大了！ === -是不是忽视提交太久了？痴迷地编码，直到现在才想起有源码控制工具这回事？提交一 -系列不相关的变更，因为那是你的风格？ +是不是忽略提交太久了？一直痴迷于写代码，直到现在才想起有源码控制工具这回事？或者 +提交一系列不相关的变更，因为你更喜欢这么做？ 别担心，运行： $ git add -p -为你做的每次修改，Git将展示给你变动的代码，并询问该变动是否应是下一次提交的一 -部分。回答“y”或者“n”。也有其他选项，比如延迟决定；键入“？”来学习更多。 +对你做过的每次修改，Git都将展示变动过的代码，并询问该变动是否应是下一次提交的一 +部分。回答“y”或者“n”。当然也有其他选项，比如延迟决定；键入“？”来学习更多。 一旦你满意，键入 $ git commit -来精确地提交你所选择的变更（阶段变更）。确信你没加上 *-a* 选项，否则Git将提交 +来精确地提交你所选择的变更（阶段变更）。注意请勿加上 *-a* 选项，否则Git将提交 所有修改。 -如果你修改了许多地方的许多文件怎么办？一个一个地查看变更令人沮丧，心态麻木。 +如果你修改了许多地方的许多文件怎么办？一个一个地查看这些变更会令人沮丧，心态麻木。 这种情况下，使用 *git add -i* ， 它的界面不是很直观，但更灵活。敲几个键，你可 以一次决定阶段或非阶段性提交几个文件，或查看并只选择特定文件的变更。作为另一 种选择，你还可以运行 *git commit --interactive* ，这个命令会在你操作完后自动 @@ -56,8 +57,8 @@ help ignore* 。 === 索引：Git的中转区域 === -当目前为止，我们已经忽略Git著名的'索引‘概念，但现在我们必须面对它，以解释上 -面发生的。索引是一个临时中转区。Git很少在你的项目和它的历史之间直接倒腾数据。 +当目前为止，我们一直在忽略Git著名的“索引”概念，但现在我们必须面对它，以解释上 +面发生的事情。索引是一个临时中转区。Git很少在你的项目和它的历史之间直接倒腾数据。 通常，Git先写数据到索引，然后拷贝索引中的数据到最终目的地。 例如， *commit -a* 实际上是一个两步过程。第一步把每个追踪文件当前状态的快照放 @@ -66,16 +67,16 @@ help ignore* 。 通常我们可以忽略索引并假装从历史中直接读并直接写。在这个情况下，我们希望更好 地控制，因此我们操作索引。我们放我们变更的一些的快照到索引中，而不是所有的， -然后永久地记录这个小心操纵的快照。 +然后永久地记录这个被小心操纵的快照。 === 别丢了你的HEAD === -HEAD好似一个游标，通常指向最新提交，随最新提交向前移动。一些Git命令让你来移动 +HEAD好似一个游标，通常指向最新提交，随最新提交向前移动。一些Git命令可让你来移动 它。 例如： $ git reset HEAD~3 -将立即向回移动HEAD三个提交。这样所有Git命令都表现得好似你没有做那最后三个提交， +这将立即将HEAD向回移动三个提交。这样所有Git命令都表现得好似你没有做那最后三个提交， 然而你的文件保持在现在的状态。具体应用参见帮助页。 但如何回到将来呢？过去的提交对将来一无所知。 @@ -84,27 +85,25 @@ HEAD好似一个游标，通常指向最新提交，随最新提交向前移动 $ git reset 1b6d -但假设你从来没有记下呢？别担心，像这些命令，Git保存原先的Head为一个叫 -ORIG_HEAD的标记，你可以安全体面的返回： +但假设你从来没有记下呢？别担心，在这些命令里面，Git会将原先的Head保存为一个叫做 +ORIG_HEAD的标记，你可以安全体面的返回那里： $ git reset ORIG_HEAD === HEAD捕猎 === -或许ORIG_HEAD不够。或许你刚认识到你犯了个历史性的错误，你需要回到一个早已忘记 +或许ORIG_HEAD还不够；或许你刚认识到你犯了个历史性的错误，你需要回到一个早已忘记 分支上一个远古的提交。 -默认，Git保存一个提交至少两星期，即使你命令Git摧毁该提交所在的分支。难点是找 -到相应的哈希值。你可以查看在.git/objects里所有的哈希值并尝试找到你期望的。但 -有一个更容易的办法。 +默认的，Git将会将一个提交保存至少两星期，即使你命令Git摧毁该提交所在的分支。难点 +是找到相应的哈希值。你可以查看在.git/objects里所有的哈希值并尝试找到你期望的提 +交。但这里有一个更简单的办法。 Git把算出的提交哈希值记录在“.git/logs”。这个子目录引用包括所有分支上所有活 动的历史，同时文件HEAD显示它曾经有过的所有哈希值。后者可用来发现分支上一些不 小心丢掉提交的哈希值。 -The reflog command provides a friendly interface to these log files. Try - -命令reflog为访问这些日志文件提供友好的接口，试试 +命令reflog为访问这些日志文件提供了友好的接口，可以试试 $ git reflog @@ -122,7 +121,7 @@ The reflog command provides a friendly interface to these log files. Try $ git config gc.pruneexpire "30 days" -意思是一个被删除的提交会在删除30天后，且运行 *git gc* 以后，被永久丢弃。 +意思是一个被删除的提交会在删除30天并运行 *git gc* 以后，被永久丢弃。 你或许还想关掉 *git gc* 的自动运行： @@ -152,21 +151,21 @@ Git命令它们自己就是站在巨人肩膀上的脚本。通过一点修补 $ git symbolic-ref HEAD 2> /dev/null | cut -b 12- -子目录 +contrib+ 是一个基于Git工具的宝库。它们中的一些时时会被提升为官方命令。 -在Debian和Ubuntu，这个目录位于 +/usr/share/doc/git-core/contrib+ 。 +子目录 +contrib+ 是一个基于Git工具的宝库。它们中的一些命令不时的会被提升为官方 +命令。在Debian和Ubuntu，这个目录位于 +/usr/share/doc/git-core/contrib+ 。 一个受欢迎的居民是 +workdir/git-new-workdir+ 。通过聪明的符号链接，这个脚本创 建一个新的工作目录，其历史与原来的仓库共享： $ git-new-workdir an/existing/repo new/directory -这个新的目录和其中的文件可被视为一个克隆，除了既然历史是共享的，两者的树自动 -保持同步。不必合并，推入或拉出。 +这个新的目录和其中的文件可被视为一个克隆，除了历史是共享的，两者的树会自动保持 +同步，而不必合并，推入或拉出。 === 大胆的特技 === -这些天，Git使得用户意外摧毁数据变得更困难。但如若你知道你在做什么，你可以突破 -为通用命令所设的防卫保障。 +最近以来，Git努力使用户因意外而销毁数据变得更困难。但如若你知道你在做什么，你可 +以突破为通用命令所设的保障措施。 *Checkout*：未提交的变更会导致捡出失败。销毁你的变更，并无论如何都checkout一 个指定的提交，使用强制标记： @@ -184,16 +183,17 @@ Git命令它们自己就是站在巨人肩膀上的脚本。通过一点修补 $ git branch -D dead_branch # instead of -d -类似，通过移动试图覆盖分支，如果随之而来有数据丢失，也会失败。强制移动分支，键入： +类似，通过移动试图覆盖分支，如果随之而来有数据丢失，那么覆盖也会失败。强制移动 +分支，键入： $ git branch -M source target # 而不是 -m -不像checkout和重置，这两个命令延迟数据销毁。这个变更仍然存储在.git的子目录里， +不像checkout和重置，这两个命令将延迟数据销毁。这个变更仍然存储在.git的子目录里， 并且可以通过恢复.git/logs里的相应哈希值获取（参见上面 上面“HEAD猎捕”）。默 认情况下，这些数据会保存至少两星期。 *Clean*: 一些Git命令拒绝执行，因为它们担心会重装未纳入管理的文件。如果你确信 - 所有未纳入管理的文件都是消耗，那就无情地删除它们，使用： + 所有未纳入管理的文件都是消耗品，那就无情地删除它们，使用： $ git clean -f -d @@ -201,8 +201,8 @@ Git命令它们自己就是站在巨人肩膀上的脚本。通过一点修补 === 阻止坏提交 === -愚蠢的错误污染我的仓库。最可怕的是由于忘记 *git add* 而引起的文件丢失。较小 -的罪过是行末追加空格并引起合并冲突：尽管危害少，我希望浙西永远不要出现在公开 +愚蠢的错误会污染我的代码库。最可怕的是由于忘记 *git add* 而引起的文件丢失。较小 +的错误则是行末追加空格而引发合并冲突：尽管危害少，我希望这些永远不要出现在公开 记录里。 不过我购买了傻瓜保险，通过使用一个_钩子_来提醒我这些问题： @@ -210,7 +210,7 @@ Git命令它们自己就是站在巨人肩膀上的脚本。通过一点修补 $ cd .git/hooks $ cp pre-commit.sample pre-commit # 对旧版本Git，先运行chmod +x -现在Git放弃提交，如果检测到无用的空格或未解决的合并冲突。 +现在如果Git检测到无用的空格或未解决的合并冲突，它将放弃合并。 对本文档，我最终添加以下到 *pre-commit* 钩子的前面，来防止缺魂儿的事： @@ -219,8 +219,7 @@ Git命令它们自己就是站在巨人肩膀上的脚本。通过一点修补 exit 1 fi -几个git操作支持钩子；参见 *git help hooks* 。我们早先激活了作为例子的 +一部分其他的Git操作也支持钩子；参见 *git help hooks* 。我们早先激活了作为例子的 *post-update* 钩子，当讨论基于HTTP的Git的时候。无论head何时移动，这个钩子都会 -运行。例子脚本post-update更新Git在基于Git并不知晓的传输协议，诸如HTTP，通讯时 -所需的文件。 - +运行。例子中的脚本post-update会在Git面对并不知晓的传输协议，诸如HTTP时，更新自己的 +资料库，以确保它有能力交换所需的文件。 diff --git a/zh_cn/history.txt b/zh_cn/history.txt index 93526a56..e3423293 100644 --- a/zh_cn/history.txt +++ b/zh_cn/history.txt @@ -2,9 +2,9 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需要小心：只重写你独自拥有 的那部分。正如民族间会无休止的争论谁犯下了什么暴行一样，如果在另一个人的克隆 -里，历史版本与你的不同，当你们的树互操作时，你会遇到一致性方面的问题。 +里，历史版本与你的不同，当你们的树互操作时，你们会遇到一致性方面的问题。 -一些开发人员强烈地感觉历史应该永远不变，不好的部分也不变所有都不变。另一些觉 +一些开发人员强烈地感到历史应该永远不变，不好的部分也不变，所有都不变。另一些觉 得代码树在向外发布之前，应该整得漂漂亮亮的。Git同时支持两者的观点。像克隆，分 支和合并一样，重写历史只是Git给你的另一强大功能，至于如何明智地使用它，那是你 的事了。 @@ -24,35 +24,51 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 === 更复杂情况 === -假设前面的问题还要糟糕十倍。在漫长的时间里我们提交了一堆。但你不太喜欢他们的 +假设上面的问题再糟糕十倍，比如在漫长的时间里我们提交了一堆，但你不太喜欢他们的 组织方式，而且一些提交信息需要重写。那么键入： $ git rebase -i HEAD~10 -并且后10个提交会出现在你喜爱的$EDITOR。一个例子： +则最后的10个提交会出现在你喜爱的$EDITOR（即通过设置EDITOR环境变量决定使用哪个 +文本编辑器）。一个例子： pick 5c6eb73 Added repo.or.cz link pick a311a64 Reordered analogies in "Work How You Want" pick 100834f Added push target to Makefile -之后： +不像git log，列表中的提交是旧的在前，新的在后。在上面的列表中，5c6eb73是最老的 +提交，100834是最新的提交。接下来可以在$EDITOR中： - 通过删除行来移去提交。 -- 通过为行重新排序行来重新排序提交。 -- 替换 `pick` 使用： +- 通过对几行记录重新排序，来重组提交顺序。 +- 替换 `pick` 命令： * `edit` 标记一个提交需要修订。 * `reword` 改变日志信息。 - * `squash` 将一个提交与其和前一个合并。 - * `fixup` 将一个提交与其和前一个合并，并丢弃日志信息。 + * `squash` 将一个提交与其前一个合并。 + * `fixup` 将一个提交与其前一个合并，并丢弃日志信息。 -保存退出。如果你把一个提交标记为可编辑，那么运行 +比如，将第二个提交的`pick`修改为`squash`： + pick 5c6eb73 Added repo.or.cz link + squash a311a64 Reordered analogies in "Work How You Want" + pick 100834f Added push target to Makefile - $ git commit --amend +保存退出，则Git会把a311a64合并进5c6eb73。想象一下“挤压”动作，squash的作用就是 +把一个提交“挤压”进前一个提交。 -否则，运行： +“挤压”的同时，Git合并了两个提交的日志信息供编辑。比较一下*fixup*命令，其直接 +扔掉“挤压“后合并的日志信息。 + +如果你把一个提交标记为*edit*，Git会带你回到这个提交点，你可以修改当时的提交信息 +，甚至可以增加新的提交。修改完毕后执行： $ git rebase --continue +直到遇到下一个*edit*标记点，Git会回放所有遇到的提交。 + +也可以放弃修改： + + $ git rebase --abort + 这样尽早提交，经常提交：你之后还可以用rebase来规整。 === 本地变更之后 === @@ -61,7 +77,7 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 与官方版本同步。在你准备好提交到中心分支之前，这个循环会重复几次。 但现在你本地Git克隆掺杂了你的改动和官方改动。你更期望在变更列表里，你所有的变 -更能够连续。 +更能够连续列出。 这就是上面提到的 *git rebase* 所做的工作。在很多情况下你可以使用 *--onto* 标 记以避免交互。 @@ -69,9 +85,12 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 另外参见 *git help rebase* 以获取这个让人惊奇的命令更详细的例子。你可以拆分提 交。你甚至可以重新组织一棵树的分支。 +要小心的是，rebase指令非常强悍，对于复杂的rebase，最好首先使用*git clone*备份 +一下。 + === 重写历史 === -偶尔，你需要做一些代码控制，好比从正式的照片中去除一些人一样，需要从历史记录 +偶尔，你需要做一些代码控制——好比从正式的照片中去除一些人一样——你需要从历史记录 里面彻底的抹掉他们。例如，假设我们要发布一个项目，但由于一些原因，项目中的某 个文件不能公开。或许我把我的信用卡号记录在了一个文本文件里，而我又意外的把它 加入到了这个项目中。仅仅删除这个文件是不够的，因为从别的提交记录中还是可以访 @@ -82,10 +101,10 @@ Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需 参见 *git help filter-branch* ，那里讨论了这个例子并给出一个更快的方法。一般 地， *filter-branch* 允许你使用一个单一命令来大范围地更改历史。 -此后，+.git/refs/original+目录描述操作之前的状态。检查命令filter-branch的确做 -了你想要做的，然后删除此目录，如果你想运行多次filter-branch命令。 +此后，+.git/refs/original+目录描述操作之前的状态。检查命令 *filter-branch* 的 +确做了你想要做的，然后删除此目录，如果你想运行多次filter-branch命令。 -最后，用你修订过的版本替换你的项目克隆，如果你想之后和它们交互的话。 +最后，如果你想之后和修订过的版本交互的话，记得用你修订过的版本替换你的项目克隆。 === 制造历史 === @@ -143,9 +162,9 @@ EOT $ git checkout master . -命令*git fast-export* 转换任意仓库到 *git fast-import* 格式，你可以研究其输 -出来写导出程序， 也以可读格式传送仓库。的确，这些命令可以发送仓库文本文件 -通过只接受文本的渠道。 +命令*git fast-export* 可将任意仓库转换成 *git fast-import* 格式，你可以研究其输 +出来写新的导出程序， 或以人类可以理解的格式转移仓库。的确，这些命令可以通过只接受文 +本的渠道来发送仓库文件。 === 哪儿错了？ === @@ -200,24 +219,22 @@ Git使用指定命令（通常是一个一次性的脚本）的返回值来决 中心系统排斥离线工作，也需要更昂贵的网络设施，特别是当开发人员增多的时候。最 重要的是，所有操作都一定程度变慢，一般在用户避免使用那些能不用则不用的高级命 令时。在极端的情况下，即使是最基本的命令也会变慢。当用户必须运行缓慢的命令的 -时候，由于工作流被打断，生产力降低。 +时候，由于工作流被打断，生产力就会降低。 -我有这些的一手经验。Git是我使用的第一个版本控制系统。我很快学会适应了它，用了 -它提供的许多功能。我简单地假设其他系统也是相似的：选择一个版本控制系统应该和 -选择一个编辑器或浏览器没啥两样。 +我有这方面的一手经验。Git是我使用的第一个版本控制系统。我很快学会适应了它，并 +使用了它提供的许多功能。我简单地假设其他系统也是相似的：选择一个版本控制系统应 +该和选择一个编辑器或浏览器没啥两样。 -在我之后被迫使用中心系统的时候，我被震惊了。我那有些脆弱的网络没给Git带来大麻 -烦，但是当它需要像本地硬盘一样稳定的时候，它使开发困难重重。另外，我发现我自 -己有选择地避免特定的命令，以避免踏雷，这极大地影响了我，使我不能按照我喜欢的 -方式工作。 +在我之后被迫使用中心系统的时候，我被震惊到了。我那有些脆弱的网络没给Git带来 +大麻烦，但是当它需要像本地硬盘一样稳定工作的时候，它使开发变得困难重重。另 +外，我发现我自己有选择地避免使用特定的命令，以避免踏雷，这极大地影响了我，使 +我不能按照我喜欢的方式工作。 -当我不得不运行一个慢的命令的时候，这种等待极大地破坏了我思绪连续性。在等待服 -务器通讯完成的时候，我选择做其他的事情以度过这段时光，比如查看邮件或写其他的 -文档。当我返回我原先的工作场景的时候，这个命令早已结束，并且我还需要浪费时间 -试图记起我之前正在做什么。人类不擅长场景间的切换。 +当我不得不运行一个速度缓慢的命令时，这种等待极大地破坏了我思绪的连续性。在等 +待服务器通讯完成的时候，我选择做其他的事情以度过这段时光，比如查看邮件或写其 +他的文档。当我返回我原先的工作场景的时候，这个命令早已结束，并且我还需要浪费 +时间试图记起我之前正在做什么。人类并不擅长场景间的切换。 还有一个有意思的大众悲剧效应：预料到网络拥挤，为了减少将来的等待时间，每个人 -将比以往消费更多的带宽在各种操作上。共同的努力加剧了拥挤，这等于是鼓励个人下 -次消费更多带宽以避免更长时间的等待。 - - +将比以往消费更多的带宽在各种操作上。大家共同的努力结果加剧了拥挤，这等于是鼓 +励个人下次消费更多带宽以避免更长的等待时间。 diff --git a/zh_cn/intro.txt b/zh_cn/intro.txt index 905b10c8..5b170acd 100644 --- a/zh_cn/intro.txt +++ b/zh_cn/intro.txt @@ -1,15 +1,15 @@ == 入门 == -我将用类比方式来介绍版本控制的概念。更严谨的解释参见 +我将用类比的方式来介绍版本控制的概念。更严谨的解释参见 http://en.wikipedia.org/wiki/Revision_control[维基百科版本修订控制条目]。 === 工作是玩 === -我从小就玩电脑游戏。相反，我只是在长大后才开始使用版本控制系统。我想我并不特 -殊，并且，对比两者工作方式可使这些概念更易解释，也易于理解。 +我从小就玩电脑游戏，直到今天；不过我只是在长大后才开始使用版本控制系统。我 +想我并不是个例，所以拿两者工作方式进行类比，可使一些概念更易解释，也易于理解。 -编写代码，或编辑文档和玩游戏差不多。在你做出了很多进展之后，你最好保存一下。 -去做这个，会点击你所信任的编辑器保存按钮就好了。 +编写代码，或编辑文档，和玩游戏差不多。在你做出了很多进展之后，你最好保存一下。 +要做到这点，点击你所信任的编辑器保存按钮就好了。 但这将覆盖老版本。就像那些学校里玩的老游戏，只有一个存档：你确实可以保存，但 你不能回到更老的状态了。这真让人扫兴，因为那个状态可能恰好保存了这个游戏特别 @@ -19,8 +19,9 @@ http://en.wikipedia.org/wiki/Revision_control[维基百科版本修订控制条 === 版本控制 === 在编辑的时候，如果想保留旧版本，你可以将文件“另存为”一个不同的文件，或在保 -存之前将文件拷贝到别处。你可能压缩这些文件以节省空间。这是一个初级的靠手工的 -版本控制方式。游戏软件早就提高了这块，很多都提供多个基于时间戳的自动存档槽。 +存之前将文件拷贝到别处。你可能会压缩这些文件以节省空间。这是一个初级的依赖 +手工进行的版本控制方式。游戏软件在这块早就做了很多提高，很多游戏都提供基于 +时间戳的多个存档槽。 让我们看看稍稍复杂的情况。比如你有很多放在一起的文件，比如项目源码，或网站文 件。现在如你想保留旧版本，你不得不把整个目录存档。手工保存多个版本很不方便， @@ -29,38 +30,38 @@ http://en.wikipedia.org/wiki/Revision_control[维基百科版本修订控制条 在一些电脑游戏里，一个存档真的包含在一个充满文件的目录里。这些游戏为玩家屏蔽 了这些细节，并提供一个方便易用的界面来管理该目录的不同版本。 -版本控制系统也没有两样。两者提供友好的界面，来管理目录里的东西。你可以频繁保 -存，也可以之后加载任一保存。不像大多计算机游戏，版本控制系统通常精于节省存储 -空间。一般情况如果两个版本间只有少数文件的变更，每个文件的变更也不大，那就只 -存储差异的部分，而不是把全部拷贝的都保存下来，以节省存储空间。 +版本控制系统也没有不同。两者提供友好的用户界面，来管理目录里的东西。你可以频 +繁保存，也可以之后加载任一存档。不像大多数计算机游戏，版本控制系统通常精于节 +省存储空间。一般情况下，如果两个版本间只有少数文件的变更，每个文件的变更也不 +大，那就只存储差异的部分，而不是把全部拷贝的都保存下来，以节省存储空间。 === 分布控制 === 现在设想一个很难的游戏。太难打了，以至于世界各地很多骨灰级玩家决定组队，分享 -他们游戏存档以攻克它。Speedrun们就是实际中的例子：在同一个游戏里，玩家们分别 +他们游戏存档以攻克它。Speedrun就是现实中的例子：在同一个游戏里，玩家们分别 攻克不同的等级，协同工作以创造惊人战绩。 你如何搭建一个系统，使得他们易于得到彼此的存档？并易于上载新的存档？ 在过去，每个项目都使用中心式版本控制。某个服务器上放所有保存的游戏记录。其他 -人就不用了。每个玩家在他们机器上最多保留几个游戏记录。当一个玩家想更新进度时 -候，他们需要把最新进度从主服务器下载下来，玩一会儿，保存并上载到主服务器以供 -其他人使用。 +人就不用再做备份了。每个玩家在他们机器上最多保留几个游戏记录。当一个玩家想更 +新至最新进度时候，他们需要把这个进度从主服务器下载下来，玩一会儿，保存并上载 +到主服务器以供其他人使用。 -假如一个玩家由于某种原因，想得到一个较旧版本的游戏进度怎么样？或许当前保存的 +假如一个玩家由于某种原因，想得到一个较旧版本的游戏进度该怎么办？或许当前保存的 游戏是一个注定的败局，因为某人在第三级忘记捡某个物品；他们希望能找到最近一个 可以完成的游戏记录。或者他们想比较两个旧版本间的差异，来估算某个特定玩家干了 多少活。 -查看旧版本的理由有很多，但检查的办法都是一样的。他们必须去问中心服务器要那个 +查看旧版本的理由有很多，但检查的办法都是一样的。他们必须去中心服务器索要那个 旧版本的记录。需要的旧版本越多，和服务器的交互就越多。 -新一代的版本控制系统，Git就是其中之一，是分布式的，可以被认作广义上的中心式系 -统。从主服务器下载时玩家会得到所有保存的记录，而不仅是最新版。这看起来他们好 -像把中心服务器做了个镜像。 +Git是新一代的版本控制系统中的一员，它的特点是分布式的，广义上也可以被看作是一 +种中心式系统。从主服务器下载时，玩家会得到所有保存的记录，而不仅是最新版。这 +看来，玩家们好像把中心服务器做了个镜像。 -最初的克隆操作可能比较费时，特别当有很长历史的时，但从长远看这是值得的。一个 -显而易见的好处是，当查看一个旧版本时，不再需要和中心服务器通讯了。 +最初的克隆操作可能比较费时，特别当存档有很长历史的时候，但从长远看这是值得的。一 +个显而易见的好处是，当查看一个旧版本时，就不再需要和中心服务器通讯了。 === 一个误区 === @@ -68,11 +69,11 @@ http://en.wikipedia.org/wiki/Revision_control[维基百科版本修订控制条 相符。给谁照相也不会偷走他们的灵魂。类似地，克隆主仓库并不降低它的重要性。 一般来说，一个中心版本控制系统能做的任何事，一个良好设计的分布式系统都能做得 -更好。网络资源总要比本地资源耗费更费。不过我们应该在稍后分析分布式方案的缺点， +更好。网络资源总要比本地资源耗费更昂贵。不过我们应该在稍后分析分布式方案的缺点， 这样人们才不会按照习惯做出错误的比较。 -一个小项目或许只需要分布式系统提供的一小部分功能，但是，在项目很小的时候，应 -该用规划不好的系统？就好比说，在计算较小数目的时候应该使用罗马数字？ +一个小项目或许只需要分布式系统提供的一小部分功能，但是，在项目很小的时候，就理应 +使用规划并不好的系统？就好比说，在计算较小数目的时候应该使用罗马数字？ 而且，你的项目的增长可能会超出你最初的预期。从一开始就使用Git好似带着一把瑞士 军刀，尽管你很多时候只是用它来开开瓶盖。某天你迫切需要一把改锥，你就会庆幸你 @@ -92,4 +93,3 @@ Bob两人的改动都会生效。 更复杂的情况也可能出现。版本控制系统自己处理相对简单的情况，把困难的情况留给 人来处理。它们的行为通常是可配置的。 - diff --git a/zh_cn/multiplayer.txt b/zh_cn/multiplayer.txt index c0726009..250baf09 100644 --- a/zh_cn/multiplayer.txt +++ b/zh_cn/multiplayer.txt @@ -1,34 +1,34 @@ == 多人Git == -我最初在一个私人项目上使用Git，那里我是唯一的开发。在与Git分布式本性有关的命 -令中，我只用到了 *pull* 和 *clone*，用以在不同地方保持同一个项目。 +我最初在一个私人项目上使用Git，我是那个项目的唯一的开发者。在与Git分布式特性 +有关的命令中，我只用到了 *pull* 和 *clone*，以此即可在不同地方保持项目同步。 后来我想用Git发布我的代码，并且包括其他贡献者的变更。我不得不学习如何管理有来 自世界各地的多个开发的项目，幸运的是，这是Git的长处，也可以说是其存在的理由。 === 我是谁？ === -每个提交都有一个作者姓名和电子信箱，这显示在 *git log* 里。默认， Git使用系统 -设定来填充这些域。要显示地设定，键入： +每个提交都有一个作者姓名和电子信箱，这显示在 *git log* 里。Git使用系统默认 +设定来填充这些信息。要设定这些信息，键入： $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -去掉global选项设定只对当前仓库生效。 +去掉global选项设定则只对当前仓库生效。 -=== Git在SSH, HTTP上 === +=== Git在SSH, HTTP上的使用 === -假设你有ssh访问权限，以访问一个网页服务器，但上面并没有安装Git。尽管比着它的 +假设你有ssh访问权限，可以访问一个网页服务器，但上面并没有安装Git。尽管比它的 原生协议效率低，Git也是可以通过HTTP来进行通信的。 -那么在你的帐户下，下载，编译并安装Git。在你的网页目录里创建一个Git仓库： +在你的帐户下，下载，编译并安装Git，并在你的网页目录里创建一个Git仓库： $ GIT_DIR=proj.git git init $ cd proj.git $ git --bare update-server-info $ cp hooks/post-update.sample hooks/post-update -对较老版本的Git，只拷贝还不够，你应运行： +对较老版本的Git，只拷贝还不够，你还要运行： $ chmod a+x hooks/post-update @@ -36,16 +36,16 @@ $ git push web.server:/path/to/proj.git master -那随便谁都可以通过如下命令得到你的项目： +而随便任何人都可以通过如下命令来取得你的项目： $ git clone http://web.server/proj.git -=== Git在随便什么上 === +=== Git在随便什么上的使用 === -想无需服务器，甚至无需网络连接的时候同步仓库？需要在紧急时期凑合一下？我们 -已经看过<<makinghistory, *git fast-export* 和 *git fast-import* 可以转换资源 -库到一个单一文件以及转回来>>。 我们可以来来会会传送这些文件以传输git仓库， -通过任何媒介，但一个更有效率的工具是 *git bundle* 。 +若想不依赖服务器，甚至无需网络连接来同步仓库？需要在紧急时期凑合一下？我们 +已经看过<<makinghistory, *git fast-export* 和 *git fast-import* 可以转换 +资源库到一个单一文件以及转回来>>。 我们可以通过任何媒介，来来回回传送这些文件 +以同步git仓库。但一个更有效率的工具是 *git bundle* 。 发送者创建一个“文件包”： @@ -60,13 +60,13 @@ 接收者甚至可以在一个空仓库做这个。不考虑大小， +somefile+ 可以包含整个原先 git仓库。 -在较大的项目里，可以通过只打包其他仓库缺少的变更消除浪费。例如，假设提交 +在较大的项目里，可以通过只打包其他仓库缺少的变更来消除存储浪费。例如，假设提交 ``1b6d...''是两个参与者共享的最近提交： $ git bundle create somefile HEAD ^1b6d -如果做的频繁，人可能容易忘记刚发了哪个提交。帮助页面建议使用标签解决这个问题。 -即，在你发了一个文件包后，键入： +如果提交频繁，人们可能很容易忘记刚发送了哪个提交。帮助页面建议使用标签解决这个问 +题。即，在你发了一个文件包后，键入： $ git tag -f lastbundle HEAD @@ -76,10 +76,10 @@ git仓库。 === 补丁：全球货币 === -补丁是变更的文本形式，易于计算机理解，人也类似。补丁可以通吃。你可以给开发电 -邮一个补丁，不用管他们用的什么版本控制系统。只要你的观众可以读电子邮件，他们 -就能看到你的修改。类似，在你这边，你只需要一个电子邮件帐号：不必搭建一个在线 -的Git仓库。 +补丁是变更的文本形式，易于计算机理解，人也类似。补丁可以通吃。你可以给开发者电 +邮一个补丁，不用管他们用的什么版本控制系统，只要对方可以读电子邮件，他们就能看 +到你的修改。类似的，在你这边，你只需要一个电子邮件帐号，而不必搭建一个在线的Git +仓库。 回想一下第一章： @@ -91,7 +91,7 @@ git仓库。 来打这个补丁。 -在更正式些的设置里，当作者名字以及或许签名应该记录下的时候，为过去某一刻生成 +在更正式些的设置里，当作者名字以及或许签名应该被记录下的时候，为过去某一刻生成 补丁，键入： $ git format-patch 1b6d @@ -104,9 +104,9 @@ git仓库。 $ git am < email.txt -这就打了补丁并创建了一个提交，包含诸如作者之类的信息。 +这就打了补丁并创建了一个提交，其自动包含了诸如作者之类的信息。 -使用浏览器邮件客户端，在保存补丁为文件之前，你可能需要建一个按钮，看看邮件内 +使用浏览器的邮件客户端，在保存补丁为文件之前，你可能需要建一个按钮，看看邮件内 容原来的原始形式。 对基于mbox的邮件客户端有些微不同，但如果你在使用的话，你可能是那种能轻易找出 @@ -114,12 +114,12 @@ git仓库。 === 对不起，移走了 === -克隆一个仓库后，运行 *git push* 或 *git pull* 讲自动推到或从原先URL拉。Git -如何做这个呢？秘密在和克隆一起创建的配置选项。让我们看一下： +克隆一个仓库后，运行 *git push* 或 *git pull* 将自动推到或从原先的仓库URL拉出 +新内容。Git如何做这个呢？秘密在于同克隆一起创建的配置选项里面。让我们看一下： $ git config --list -选项 +remote.origin.url+ 控制URL源；``origin'' 是给源仓库的昵称。和 +选项 +remote.origin.url+ 控制仓库的URL源；``origin'' 是给源仓库的昵称。和 ``master'' 分支的惯例一样，我们可以改变或删除这个昵称，但通常没有理由这么做。 如果原先仓库移走，我们可以更新URL，通过： @@ -139,8 +139,8 @@ pull也将忠实地跟着原来的分支。 === 远端分支 === -当你克隆一个仓库，你也克隆了它的所有分支。你或许没有注意到因为Git将它们隐藏 -起来了：你必须明确地要求。这使得远端仓库里的分支不至于干扰你的分支，也使 +当你克隆了一个仓库，你也克隆了它的所有分支。你或许没有注意到这点，因为Git将它们 +隐藏起来了：你必须明确地要求。这使得远端仓库里的分支不至于干扰你的分支，也使 Git对初学者稍稍容易些。 列出远端分支，使用： @@ -165,19 +165,20 @@ Git对初学者稍稍容易些。 === 多远端 === -假设另两个开发在同一个项目上工作，我们希望保持两个标签。我们可以同事跟多个仓库： +假设另两个开发在同一个项目上工作，我们希望保持两个标签。我们可以同时跟踪多个 +仓库： $ git remote add other git://example.com/some_repo.git $ git pull other some_branch -现在我们已经从第二个仓库合并到一个分支，并且我们已容易访问所有仓库的所有 +现在我们已经合并到第二个仓库的一个分支，并且我们已容易访问所有仓库的所有 分支。 $ git diff origin/experimental^ other/some_branch~5 但如果为了不影响自己的工作，我们只想比较他们的变更怎么办呢？换句话说，我们想 -检查一下他们的分支，又不使他们的变更入侵我们的工作目录。那不是运行pull命令， -而是运行： +检查一下他们的分支，又不使他们的变更入侵我们的工作目录。这里我们并不要运行pull +命令，而是运行： $ git fetch # Fetch from origin, the default. $ git fetch other # Fetch from the second programmer. diff --git a/zh_cn/secrets.txt b/zh_cn/secrets.txt index c7c52852..c26dff38 100644 --- a/zh_cn/secrets.txt +++ b/zh_cn/secrets.txt @@ -1,24 +1,24 @@ == 揭开面纱 == -我们揭开Git神秘面纱，往里瞧瞧它是如何创造奇迹的。我会跳过细节。更深入的描述参 -见 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[ 用户手 -册]。 +我们揭开Git神秘面纱，往里瞧瞧它是如何创造奇迹的。我会跳过细节，若要更深入的了解Git +工作原理，可参见 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[ 用 +户手册]。 === 大象无形 === Git怎么这么谦逊寡言呢？除了偶尔提交和合并外，你可以如常工作，就像不知道版本控 -制系统存在一样。那就是，直到你需要它的时候，而且那是你欢欣的时候，Git一直默默 -注视着你。 +制系统存在一样。那就是，直到你需要它，并且感到时间合适的时候以外，Git都只是默 +默在后台看顾着你。 其他版本控制系统强迫你与繁文缛节和官僚主义不断斗争。文件的权限可能是只读的， -除非你显式地告诉中心服务器哪些文件你打算编辑。即使最基本的命令，随着用户数目 +除非你明确地告诉中心服务器哪些文件你打算编辑。即使最基本的命令，随着用户数目 的增多，也会慢的像爬一样。中心服务器可能正跟踪什么人，什么时候check out了什么 代码。当网络连接断了的时候，你就遭殃了。开发人员不断地与这些版本控制系统的种 种限制作斗争。一旦网络或中心服务器瘫痪，工作就嘎然而止。 与之相反，Git简单地在你工作目录下的`.git`目录保存你项目的历史。这是你自己的历 史拷贝，因此你可以保持离线，直到你想和他人沟通为止。你拥有你的文件命运完全的 -控制权，因为Git可以轻易在任何时候从`.git`重建一个保存状态。 +控制权，因为Git可以轻易在任何时候从`.git`重建一个曾经保存过的状态。 === 数据完整性 === @@ -34,14 +34,14 @@ Git怎么这么谦逊寡言呢？除了偶尔提交和合并外，你可以如 个简单的观察出奇地有用：查看“哈希链”。我们之后会看Git如何利用这一点来高效地 保证数据完整性。 -简言之，Git把你数据保存在`.git/objects`子目录，那里看不到正常文件名，相反你只 +简言之，Git把数据保存在`.git/objects`子目录，那里看不到正常文件名，相反你只 看到ID。通过用ID作为文件名，加上一些文件锁和时间戳技巧，Git把任意一个原始的文 件系统转化为一个高效而稳定的数据库。 === 智能 === Git是如何知道你重命名了一个文件，即使你从来没有明确提及这个事实？当然，你或许 -是运行了 *git mv* ，但这个命令和 *git add* 紧接 *git rm* 是完全一样的。 +是运行了 *git mv* ，但这个命令和 *git add* 紧随 *git rm* 是完全一样的。 Git启发式地找出相连版本之间的重命名和拷贝。实际上，它能检测文件之间代码块的移 动或拷贝！尽管它不能覆盖所有的情况，但它已经做的很好了，并且这个功能也总在改 @@ -50,34 +50,34 @@ Git启发式地找出相连版本之间的重命名和拷贝。实际上，它 === 索引 === -为每个加入管理的文件，Git在一个名为“index”的文件里记录统计信息，诸如大小， -创建时间和最后修改时间。为了确定文件是否更改，Git比较其当前统计信息与那些在索 -引里的统计信息。如果一致，那Git就跳过重新读文件。 +对每个加入库中管理的文件，Git都会在一个名为“index”的文件里记录统计信息，诸如 +大小，创建时间和最后修改时间。为了确定文件是否被更改，Git会将当前统计信息同那 +些在索引里的统计信息对比。如果一致，那Git就跳过该文件。 因为统计信息的调用比读文件内容快的很多，如果你仅仅编辑了少数几个文件，Git几乎 不需要什么时间就能更新他们的统计信息。 我们前面讲过索引是一个中转区。为什么一堆文件的统计数据是一个中转区？因为添加 -命令将文件放到Git的数据库并更新它们的统计信息，而无参数的提交命令创建一个提交， -只基于这些统计信息和已经在数据库里的文件。 +命令将文件放到Git的数据库并更新它们的统计信息，而无参数的提交命令将只基于统计 +信息和已经在数据库里的文件来创建一个全新的提交。 === Git的源起 === -这个 http://lkml.org/lkml/2005/4/6/121[ Linux内核邮件列表帖子] 描述了导致Git -的一系列事件。整个讨论线索是一个令人着迷的历史探究过程，对Git史学家而言。 +这个 http://lkml.org/lkml/2005/4/6/121[ Linux内核邮件列表帖子] 描述了导致 +Git诞生的一系列事件。对Git史学家而言，整个讨论线是一个令人着迷的历史探究过程。 === 对象数据库 === -你数据的每个版本都保存在“对象数据库”里，其位于子目录`.git/objects`；其他位 +你数据的每个版本都保存在“对象数据库”里，其位于子目录`.git/objects`内；其他位 于`.git/`的较少数据：索引，分支名，标签，配置选项，日志，头提交的当前位置等。 对象数据库朴素而优雅，是Git的力量之源。 -`.git/objects`里的每个文件是一个对象。有3中对象跟我们有关：“blob”对象， +`.git/objects`里的每个文件是一个对象。有3种对象跟我们有关：“blob”对象， “tree”对象，和“commit”对象。 === Blob对象 === -首先来一个小把戏。去一个文件名，任意文件名。在一个空目录： +首先来一个小把戏。选择一个文件名，任意文件名。在一个空目录： $ echo sweet > YOUR_FILENAME $ git init @@ -90,8 +90,8 @@ Git启发式地找出相连版本之间的重命名和拷贝。实际上，它 "blob" SP "6" NUL "sweet" LF -是 aa823728ea7d592acc69b36875a482cdf3fd5c8d，这里SP是一个空格，NUL是一个0字节， -LF是一个换行符。你可以验证这一点，键入： +是 aa823728ea7d592acc69b36875a482cdf3fd5c8d，这里SP是一个空格，NUL是一 +个0字节，LF是一个换行符。你可以验证这一点，键入： $ printf "blob 6\000sweet\n" | sha1sum @@ -100,17 +100,18 @@ Git基于“内容寻址”：文件并不按它们的文件名存储，而是 在某种意义上我们通过他们内容放置文件。开始的“blob 6”只是一个包含对象类型与 其长度的头；它简化了内部存储。 -这样我可以轻易语言你所看到的。文件名是无关的：只有里面的内容被用作构建blob对象。 +这样我可以轻易预言你所看到的输出：文件名是无关的：只有里面的内容被用作构 +建blob对象。 -你可能想知道对相同的文件什么会发生。试图加一个你文件的拷贝，什么文件名都行。 -在 +.git/objects+ 的内容保持不变，不管你加了多少。Git只存储一次数据。 +你可能想知道对相同的文件会发生什么。试图填加一个你文件的拷贝，什么文件名都行。 +在 +.git/objects+ 的内容保持不变，不管你加了多少。Git都只存储一次数据。 顺便说一句，在 +.git/objects+ 里的文件用zlib压缩，因此你不应该直接查看他们。 可以通过http://www.zlib.net/zpipe.c[zpipe -d] 管道， 或者键入： $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d -这漂亮地打印出给定的对象。 +这样可以漂亮地打印出给定的对象。注意，上面的cat-file命令中，aa是目录名。 === Tree对象 === @@ -126,11 +127,12 @@ Git基于“内容寻址”：文件并不按它们的文件名存储，而是 $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose' $ find .git/objects -type f -现在你硬看到文件 +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+ ，因为这是以下内容的SHA1哈希值： +现在你应看到文件 +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+ ，因 +为这是以下内容的SHA1哈希值： "tree" SP "32" NUL "100644 rose" NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d -检查这个文件真的包含上面内容通过键入： +通过键入以下命令来检查这个文件真的包含上面内容： $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch @@ -138,21 +140,21 @@ Git基于“内容寻址”：文件并不按它们的文件名存储，而是 $ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum -与查看文件相比，哈希值验证更技巧一些，因为其输出不止包含原始未压缩文件。 +与查看文件相比，哈希值验证更轻巧一些，因为其输出不包含原始未压缩文件。 -这个文件是一个“tree”对象：一组数据包含文件类型，文件名和哈希值。在我们的例 +这里的输出是一个“tree”对象：一组包含文件类型，文件名和哈希值的数据。在我们的例 子里，文件类型是100644，这意味着“rose”是一个一般文件，并且哈希值指blob对象， 包含“rose”的内容。其他可能文件类型有可执行，链接或者目录。在最后一个例子里， 哈希值指向一个tree对象。 -在一些过渡性的分支，你会有一些你不在需要的老的对象，尽管有宽限过期之后，它们 -会被自动清除，现在我们还是将其删除，以使我们比较容易跟上这个玩具例子。 +在一些过渡性的分支，你会有一些你不再需要的老的对象，尽管在宽限过期之后，它们 +会被自动清除，现在我们还是将其删除，以使我们比较容易跟上这个示范的例子。 $ rm -r .git/refs/original $ git reflog expire --expire=now --all $ git prune -在真实项目里你通常应该避免像这样的命令，因为你在破换备份。如果你期望一个干净 +在真实项目里你通常应该避免像这样的命令，因为你在破坏备份。如果你期望一个干净 的仓库，通常最好做一个新的克隆。还有，直接操作 +.git+ 时一定要小心：如果 Git命令同时也在运行会怎样，或者突然停电？一般，引用应由 *git update-ref -d* 删除，尽管通常手工删除 +refs/original+ 也是安全的。 @@ -160,7 +162,7 @@ Git命令同时也在运行会怎样，或者突然停电？一般，引用应 === Commit对象 === 我们已经解释了三个对象中的两个。第三个是“commit”对象。其内容依赖于提交信息 -以及其创建的日期和时间。为满足这里我们所有的，我们不得不调整一下： +以及其创建的日期和时间。为满足这里我们所需的，我们不得不调整一下： $ git commit --amend -m Shakespeare # 改提交信息 $ git filter-branch --env-filter 'export @@ -191,25 +193,25 @@ Git命令同时也在运行会怎样，或者突然停电？一般，引用应 Git的秘密似乎太简单。看起来似乎你可以整合几个shell脚本，加几行C代码来弄起来， 也就几个小时的事：一个基本文件操作和SHA1哈希化的混杂，用锁文件装饰一下，文件 同步保证健壮性。实际上，这准确描述了Git的最早期版本。尽管如此，除了巧妙地打包 -以节省空间，巧妙地索引以省时间，我们现在知道Git如何灵巧地改造文件系统成为一个 -对版本控制完美的数据库。 +以节省空间，巧妙地索引以省时间，我们现在知道Git如何灵巧地改造文件系统，使其成 +为一个完美的版本控制数据库。 例如，如果对象数据库里的任何一个文件由于硬盘错误损毁，那么其哈希值将不再匹配， 这个错误会报告给我们。通过哈希化其他对象的哈希值，我们在所有层面维护数据完整 -性。Commit对象是原子的，也就是说，一个提交永远不会部分地记录变更：在我们已经 -存储所有相关tree对象，blob对象和父commit对象之后，我们才可以计算提交的的哈希 +性。Commit对象是原子性的，也就是说，一个提交永远不会部分地记录变更：在我们已经 +存储所有关于tree对象，blob对象和父commit对象之后，我们才可以计算提交的的哈希 值并将其存储在数据库，对象数据库不受诸如停电之类的意外中断影响。 -我们打败即使是最狡猾的对手。假设有谁试图悄悄修改一个项目里一个远古版本文件的 -内容。为使对象据库看起来健康，他们也必须修改相应blob对象的哈希值，既然它现在 -是一个不同的字节串。这意味着他们讲不得不引用这个文件的tree对象的哈希值，并反 +我们打败了即使是最狡猾的对手。假设有人试图悄悄修改一个项目里一个远古版本文件的 +内容，为使对象据库看起来健康，他们也必须修改相应blob对象的哈希值，既然它现在 +是一个不同的字节串。这意味着他们将不得不引用这个文件的tree对象的哈希值，并反 过来改变所有与这个tree相关的commit对象的哈希值，还要加上这些提交所有后裔的哈 希值。这暗示官方head的哈希值与这个坏仓库不同。通过跟踪不匹配哈希值线索，我 们可以查明残缺文件，以及第一个被破坏的提交。 -总之，只要20个字节代表最后一次提交的是安全的，不可能篡改一个Git仓库。 +总之，只要20个字节代表最后一次的提交是安全的，我们就将不可能篡改一个Git仓库。 -那么Git的著名功能怎样呢？分支？合并？标签？单纯的细节。当前head保存在文件 -+.git /HEAD+ ，其中包含了一个commit对象的哈希值。该哈希值在运行提交以及其他命 -令是更新。分支几乎一样：它们是保存在 +.git/refs/heads+ 的文件。标签也是：它们 -住在住在 +.git/refs/tags+ ，但它们由一套不同的命令更新。 +那么Git的著名功能怎样实现的呢？分支？合并？标签？这些都是单纯的细节。当前head保 +存在文件+.git /HEAD+ ，其中包含了一个commit对象的哈希值。该哈希值在运行提交 +以及其他命令时更新。分支几乎一样：它们是保存在 +.git/refs/heads+ 的文件。标签 +也是：它们住在 +.git/refs/tags+ ，但它们由一套不同的命令更新。 diff --git a/zh_cn/translate.txt b/zh_cn/translate.txt index c11c70c5..81a8a2f7 100644 --- a/zh_cn/translate.txt +++ b/zh_cn/translate.txt @@ -10,8 +10,8 @@ http://www.w3.org/International/articles/language-tags/Overview.en.php[ W3C在 国际化方面的文章 ]。例如，英语是“en”，日语是“ja”，正体中文是“zh-Hant”。 然后在新建目录，翻译这些来自“en”目录的 +txt+ 文件。 -例如，将本指南译为 http://en.wikipedia.org/wiki/Klingon_language[ 克林贡语 ]， -你也许键入： +例如，要将本指南译为 http://en.wikipedia.org/wiki/Klingon_language[ 克林贡语 ]， +你可以键入： $ git clone git://repo.or.cz/gitmagic.git $ cd gitmagic @@ -28,9 +28,8 @@ http://www.w3.org/International/articles/language-tags/Overview.en.php[ W3C在 $ make tlh $ firefox book-tlh/index.html -经常提交你的变更，然后然我知道他们什么时候完成。GitHub.com提供一个便于fork +经常提交你的更新，这样我就知道他们什么时候可以完成。GitHub.com提供一个便于fork “gitmatic”项目的界面，提交你的变更，然后告诉我去合并。 但请按照最适合你的方式做：例如，中文译者就使用 -Google Docs。只要你的工作使更多人看到我的工作，我就高兴。 - +Google Docs。只要你的工作能使更多人看到我的工作，我就高兴。