Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Merge branch 'master' of https://github.com/progit/progit

Conflicts:
	zh-tw/01-introduction/01-chapter1.markdown
  • Loading branch information...
commit e4ddfe1a7f2f1cfb0c9fa26ec6837d8a057c7707 2 parents 64a56f0 + 5e404b9
@dodowell dodowell authored
Showing with 5,733 additions and 571 deletions.
  1. +1 −1  ar/01-introduction/01-chapter1.markdown
  2. +1 −1  ar/03-git-branching/01-chapter3.markdown
  3. +2 −1  ar/08-git-and-other-scms/01-chapter8.markdown
  4. +2 −2 az/01-introduction/01-chapter1.markdown
  5. +2 −1  az/08-git-and-other-scms/01-chapter8.markdown
  6. +2 −2 be/01-introduction/01-chapter1.markdown
  7. +2 −2 ca/01-introduction/01-chapter1.markdown
  8. +2 −1  ca/08-git-and-other-scms/01-chapter8.markdown
  9. +2 −2 cs/01-introduction/01-chapter1.markdown
  10. +1 −0  cs/02-git-basics/01-chapter2.markdown
  11. +16 −17 cs/04-git-server/01-chapter4.markdown
  12. +1 −1  cs/08-git-and-other-scms/01-chapter8.markdown
  13. +2 −2 de/01-introduction/01-chapter1.markdown
  14. +1 −1  de/06-git-tools/01-chapter6.markdown
  15. +3 −2 de/08-git-and-other-scms/01-chapter8.markdown
  16. +2 −2 en/01-introduction/01-chapter1.markdown
  17. +3 −2 en/02-git-basics/01-chapter2.markdown
  18. +24 −25 en/04-git-server/01-chapter4.markdown
  19. +1 −1  en/08-git-and-other-scms/01-chapter8.markdown
  20. +2 −2 eo/01-introduction/01-chapter1.markdown
  21. +0 −257 es-mx/01-introduction/01-chapter1.markdown
  22. +2 −2 es-ni/01-introduction/01-chapter1.markdown
  23. +1 −1  es-ni/03-git-branching/01-chapter3.markdown
  24. +2 −1  es-ni/08-git-and-other-scms/01-chapter8.markdown
  25. +2 −2 es/01-introduction/01-chapter1.markdown
  26. +2 −1  es/08-git-and-other-scms/01-chapter8.markdown
  27. +2 −2 fi/01-introduction/01-chapter1.markdown
  28. +3 −3 fr/01-introduction/01-chapter1.markdown
  29. +2 −1  fr/02-git-basics/01-chapter2.markdown
  30. +15 −15 fr/04-git-server/01-chapter4.markdown
  31. +1 −1  fr/07-customizing-git/01-chapter7.markdown
  32. +5 −5 fr/08-git-and-other-scms/01-chapter8.markdown
  33. +2 −2 hu/01-introduction/01-chapter1.markdown
  34. +2 −2 id/01-introduction/01-chapter1.markdown
  35. +2 −2 it/01-introduction/01-chapter1.markdown
  36. +2 −2 ja/01-introduction/01-chapter1.markdown
  37. +1 −1  ja/03-git-branching/01-chapter3.markdown
  38. +2 −1  ja/08-git-and-other-scms/01-chapter8.markdown
  39. +1 −1  ko/01-introduction/01-chapter1.markdown
  40. +2 −1  ko/08-git-and-other-scms/01-chapter8.markdown
  41. +12 −3 latex/makepdf
  42. +2 −1  latex/template.tex
  43. +71 −46 makeebooks
  44. +2 −2 mk/01-introduction/01-chapter1.markdown
  45. +1 −1  mk/03-git-branching/01-chapter3.markdown
  46. +2 −1  mk/08-git-and-other-scms/01-chapter8.markdown
  47. +2 −2 nl/01-introduction/01-chapter1.markdown
  48. +2 −1  nl/08-git-and-other-scms/01-chapter8.markdown
  49. +2 −2 no-nb/01-introduction/01-chapter1.markdown
  50. +2 −1  no-nb/08-git-and-other-scms/01-chapter8.markdown
  51. +2 −2 pl/01-introduction/01-chapter1.markdown
  52. +1 −1  pt-br/01-introduction/01-chapter1.markdown
  53. +2 −1  pt-br/08-git-and-other-scms/01-chapter8.markdown
  54. +2 −2 ro/01-introduction/01-chapter1.markdown
  55. +10 −10 ru/01-introduction/01-chapter1.markdown
  56. +7 −7 ru/03-git-branching/01-chapter3.markdown
  57. +49 −80 ru/04-git-server/01-chapter4.markdown
  58. +1 −1  ru/06-git-tools/01-chapter6.markdown
  59. +2 −1  ru/08-git-and-other-scms/01-chapter8.markdown
  60. +477 −0 ru/figures-dia/fig0501.dia
  61. +1,063 −0 ru/figures-dia/fig0502.dia
  62. +915 −0 ru/figures-dia/fig0503.dia
  63. +1,201 −0 ru/figures-dia/fig0511.dia
  64. +1,741 −0 ru/figures-dia/fig0515.dia
  65. +2 −2 sr/01-introduction/01-chapter1.markdown
  66. +2 −2 th/01-introduction/01-chapter1.markdown
  67. +1 −1  th/03-git-branching/01-chapter3.markdown
  68. +2 −1  th/08-git-and-other-scms/01-chapter8.markdown
  69. +2 −2 tr/01-introduction/01-chapter1.markdown
  70. +2 −1  tr/08-git-and-other-scms/01-chapter8.markdown
  71. +1 −1  zh-tw/01-introduction/01-chapter1.markdown
  72. +1 −1  zh-tw/03-git-branching/01-chapter3.markdown
  73. +2 −1  zh-tw/08-git-and-other-scms/01-chapter8.markdown
  74. +2 −2 zh/01-introduction/01-chapter1.markdown
  75. +19 −19 zh/02-git-basics/01-chapter2.markdown
  76. +1 −1  zh/03-git-branching/01-chapter3.markdown
  77. +2 −1  zh/08-git-and-other-scms/01-chapter8.markdown
View
2  ar/01-introduction/01-chapter1.markdown
@@ -184,7 +184,7 @@ Insert 18333fig0107.png
يمكنك تنصيب Git على نظام ويندوز بسهولة. أحد أسهل الطرق هو استخدام مشروع msysGit. يمكنك تنصيب البرنامج من صفحة المشروع على غوغل كود:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
بعد التنصيب سيكون لدين نسختين من الأداة للـ command-line في ويندوز (بالإضافة الى أداة SSH والتي ستستفيد منها لاحقاً) والأداة بالواجهة الرسومية الإعتيادية.
View
2  ar/03-git-branching/01-chapter3.markdown
@@ -315,7 +315,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch merged`:
+Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
$ git branch --merged
iss53
View
3  ar/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 az/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installing on Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
3  az/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 be/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Insert 18333fig0107.png
### Усталёўка ў Windows ###
-Усталёўка Git на Windows вельмі лёгкая. Працэдура ўсталёўкі праекта msysGit адна з найбольш лёгкіх. Проста спампуйце exe-файл інсталятара са старонкі Google Code, і выканайце яго:
+Усталёўка Git на Windows вельмі лёгкая. Працэдура ўсталёўкі праекта msysGit адна з найбольш лёгкіх. Проста спампуйце exe-файл інсталятара са старонкі GitHub, і выканайце яго:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Пасля яго ўсталёўкі вы маеце як кансольную версію (уключаюцы SSH кліент, які спатрэбіцца ў далейшым), так і стандартную графічную.
View
4 ca/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installing on Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
3  ca/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 cs/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Není nutné přidávat všechny doplňky, ale pokud budete někdy používat Gi
### Instalace v systému Windows ###
-Instalace systému Git v OS Windows je velice nenáročná. Postup instalace projektu msysGit patří k těm nejjednodušším. Ze stránky Google Code stáhněte instalační soubor exe a spusťte ho:
+Instalace systému Git v OS Windows je velice nenáročná. Postup instalace projektu msysGit patří k těm nejjednodušším. Ze stránky GitHub stáhněte instalační soubor exe a spusťte ho:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Po dokončení instalace budete mít k dispozici jak verzi pro příkazový řádek (včetně SSH klienta, který se vám bude hodit později), tak standardní grafické uživatelské rozhraní.
View
1  cs/02-git-basics/01-chapter2.markdown
@@ -577,6 +577,7 @@ To je jen několik základních parametrů k formátování výstupu pro příka
--relative-date Zobrazí datum v relativním formátu (např. "2 weeks ago", tj. před 2 týdny) místo formátu s úplným datem.
--graph Zobrazí vedle výstupu logu ASCII graf k historii větve a slučování.
--pretty Zobrazí revize v alternativním formátu. Parametry příkazu jsou oneline, short, full, fuller a format (lze zadat vlastní formát).
+ --oneline Užitečná zkratka pro `--pretty=oneline --abbrev-commit`.
### Omezení výstupu logu ###
View
33 cs/04-git-server/01-chapter4.markdown
@@ -511,7 +511,7 @@ Git se stal hodně populárním v korporátním prostředí, které obvykle mív
[gldpg]: http://sitaramc.github.com/gitolite/progit.html
[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
-Gitolite je autorizační vrstva nad gitem, která při autentizaci spoléhá na sshd nebo httpd. (Připomeňme si: autentizace spočívá v rozpoznání uživatele, autorizací rozumíme rozhodování, zda má povolení k provádění toho, co se provést pokouší.)
+Gitolite je autorizační vrstva nad gitem, která při autentizaci spoléhá na `sshd` nebo `httpd`. (Připomeňme si: autentizace spočívá v rozpoznání uživatele, autorizací rozumíme rozhodování, zda má povolení k provádění toho, co se provést pokouší.)
Gitolite umožňuje nastavit přístupová práva nejen na repozitáře (podobně jako Gitosis), ale také na větve a značky v každém repozitáři. To znamená, že lze nastavit, aby určití lidé mohli odesílat jen do určité reference (větve nebo značky) a do jiné ne.
@@ -523,15 +523,14 @@ Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý.
Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný ssh klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `VaseJmeno.pub`. Potom proveďte následující příkazy:
- git clone git://github.com/sitaramc/gitolite
- gitolite/install -ln
- # předpokládá existenci $HOME/bin a uvedení tohoto adresáře v $PATH
- gitolite setup -pk $HOME/VaseJmeno.pub
- # já bych například spustil 'gitolite setup -pk $HOME/sitaram.pub'
+ $ git clone git://github.com/sitaramc/gitolite
+ $ gitolite/install -ln
+ # předpokládá existenci $HOME/bin a uvedení tohoto adresáře v $PATH
+ $ gitolite setup -pk $HOME/scott.pub
-Nakonec přejděte zpět na pracovní stanici a spusťte `git clone git@server:gitolite-admin`.
+Poslední příkaz vytvoří na serveru nový gitovský repozitář nazvaný `gitolite-admin`.
-To je všechno! Nyní máte Gitolite nainstalovaný na serveru a v domácím adresáři vaší pracovní stanice máte také úplně nový repozitář `gitolite-admin`. Své nastavení Gitolite spravujete pomocí provádění změn v tomto repozitáři jejich odesíláním (push).
+Nakonec přejděte zpět na pracovní stanici a spusťte `git clone git@gitserver:gitolite-admin`. To je všechno! Nyní máte Gitolite nainstalovaný na serveru a v domácím adresáři vaší pracovní stanice máte také úplně nový repozitář `gitolite-admin`. Své nastavení Gitolite spravujete pomocí provádění změn v tomto repozitáři jejich odesíláním (push).
### Přizpůsobení instalace ###
@@ -546,18 +545,18 @@ Přepněte se do repozitáře `gitolite-admin` (je umístěn ve vašem domácím
conf/ keydir/
$ find conf keydir -type f
conf/gitolite.conf
- keydir/sitaram.pub
+ keydir/scott.pub
$ cat conf/gitolite.conf
repo gitolite-admin
- RW+ = sitaram
+ RW+ = scott
repo testing
RW+ = @all
-Všimněte si, že „sitaram“ (jméno veřejného klíče v dříve použitém příkazu gl-setup) má práva pro čtení i zápis k repozitáři `gitolite-admin` a také stejnojmenný veřejný klíč.
+Všimněte si, že „scott“ (jméno veřejného klíče v dříve použitém příkazu `gitolite setup`) má práva pro čtení i zápis k repozitáři `gitolite-admin` a také stejnojmenný veřejný klíč.
-Přidávání dalších uživatelů je snadné. Pokud chceme přidat uživatele „alice“, získáme její veřejný klíč, pojmenujeme jej `alice.pub` a umístíme jej do adresáře `keydir`. Je součástí klonu repozitáře gitolite-admin, který jsme právě vytvořili na pracovní stanici. Přidáme, potvrdíme a odešleme změny (add, commit, push). Tím jsme dosáhli přidání uživatele.
+Přidávání dalších uživatelů je snadné. Pokud chceme přidat uživatele „alice“, získáme její veřejný klíč, pojmenujeme jej `alice.pub` a umístíme jej do adresáře `keydir`. Je součástí klonu repozitáře `gitolite-admin`, který jsme právě vytvořili na pracovní stanici. Přidáme, potvrdíme a odešleme změny (add, commit, push). Tím jsme dosáhli přidání uživatele.
Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde uvedu jen pár zajímavých věcí.
@@ -566,8 +565,8 @@ Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skup
@oss_repos = linux perl rakudo git gitolite
@secret_repos = fenestra pear
- @admins = scott # Adams, not Chacon, sorry :)
- @interns = ashok # get the spelling right, Scott!
+ @admins = scott
+ @interns = ashok
@engineers = sitaram dilbert wally alice
@staff = @admins @engineers @interns
@@ -631,17 +630,17 @@ Gitolite vám umožní nadefinovat pro každého vývojáře jmenné prostory s
### „Wildcard“ repozitáře ###
-Gitolite vám umožní určit repozitáře zástupnými znaky (wildcards; ve skutečnosti jde o perlovské regulární výrazy) -- například k náhodnému výběru zadání příkladu můžeme použít `assignments/s[0-9][0-9]/a[0-9][0-9]`. Umožní nám též přidělit nový režim oprávnění („C“), který uživatelům povoluje vytvářet repozitáře popsané zástupnými znaky, automaticky přidělí vlastnictví konkrétnímu uživateli, který jej vytvořil, umožní mu přidělit oprávnění R a RW dalším spolupracovníkům atd. Podrobnosti opět hledejte v dokumentaci.
+Gitolite vám umožní určit repozitáře zástupnými znaky (wildcards; ve skutečnosti jde o perlovské regulární výrazy) -- například k náhodnému výběru zadání příkladu můžeme použít `assignments/s[0-9][0-9]/a[0-9][0-9]`. Umožní nám též přidělit nový režim oprávnění (`C`), který uživatelům povoluje vytvářet repozitáře popsané zástupnými znaky, automaticky přidělí vlastnictví konkrétnímu uživateli, který jej vytvořil, umožní mu přidělit oprávnění `R` a `RW` dalším spolupracovníkům atd. Podrobnosti opět hledejte v dokumentaci.
### Další vlastnosti ###
Vysvětlení Gitolite završíme přehledem několika vlastností, které jsou detailně popsány v dokumentaci.
-**Logování:** Gitolite loguje všechny úspěšné přístupy. Jestliže máte volná pravidla pro přidělování oprávnění vracet změny (práva `RW+`) a stane se, že někdo takto „zkazí“ hlavní větev, je tu ještě log soubor, který vám zachrání život, protože v něm můžete postižené SHA najít.
+**Logování:** Gitolite loguje všechny úspěšné přístupy. Jestliže máte volná pravidla pro přidělování oprávnění vracet změny (práva `RW+`) a stane se, že někdo takto „zkazí“ větev `master`, je tu ještě log soubor, který vám zachrání život, protože v něm můžete postižené SHA najít.
**Přehledy uživatelských oprávnění:** Další příjemnou vlastností je to, co se stane, pokud se pouze pokusíte připojit pomocí SSH na server. Gitolite vám ukáže, ke kterým repozitářům máte přístup a s jakoými oprávněními. Příklad:
- hello sitaram, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+ hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
R anu-wsd
R entrans
View
2  cs/08-git-and-other-scms/01-chapter8.markdown
@@ -363,7 +363,7 @@ Takový import však není úplně dokonalý a vzhledem k tomu, jak dlouho můž
Chcete-li získat seznam jmen autorů používaných v SVN, spusťte tento příkaz:
$ svn log --xml | grep -P "^<author" | sort -u | \
- perl -pe 's/<author>(.*?)<\/author>/$1 = /'
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
Vytvoříte tím log ve formátu XML. Můžete v něm vyhledávat autory, vytvořit si vlastní seznam a XML zase vyjmout. (Tento příkaz pochopitelně funguje pouze na počítačích, v nichž je nainstalován `grep`, `sort` a `perl`.) Poté tento výstup přesměrujte do souboru users.txt, abyste mohli vedle každého záznamu přidat stejná data o uživatelích Git.
View
4 de/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Du brauchst die optionalen Features natürlich nicht mit zu installieren, aber e
### Installation unter Windows ###
-Das msysGit Projekt macht die Installation von Git unter Windows sehr einfach. Lade einfach das Installationsprogramm für Windows von der Google Code Webseite herunter und führe es aus:
+Das msysGit Projekt macht die Installation von Git unter Windows sehr einfach. Lade einfach das Installationsprogramm für Windows von der GitHub Webseite herunter und führe es aus:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Danach hast Du sowohl eine Kommandozeilenversion (inklusive eines SSH Clients, der sich später noch als nützlich erweisen wird) als auch die Standard GUI installiert.
View
2  de/06-git-tools/01-chapter6.markdown
@@ -1167,7 +1167,7 @@ Switching branches with submodules in them can also be tricky. If you create a n
$ git status
# On branch master
# Untracked files:
- # (use "git add f<ile>..." to include in what will be committed)
+ # (use "git add <file>..." to include in what will be committed)
#
# rack/
View
5 de/08-git-and-other-scms/01-chapter8.markdown
@@ -487,11 +487,12 @@ Trotzdem ist der Import nicht perfekt. Und weil das ziemlich lange dauern wird,
Um eine Liste der Namen der Autoren bekommen, die SVN benutzen, kannst Du folgendes Kommando ausführen:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
<!--That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.-->
-Dies erzeugt Dir die Log-Ausgabe im XML-Format — Du suchst damit nach den Autoren, erzeugst eine Liste ohne doppelte Einträge und wirfst anschließend das überflüssige XML weg. Anschließend wird die Ausgabe in die Datei `users.txt` umgeleitet, so dass Du jedem Eintrag den entsprechenden Git-Benutzer zuordnen kannst.
+Dies erzeugt Dir die Log-Ausgabe im XML-Format — Du suchst damit nach den Autoren, erzeugst eine Liste ohne doppelte Einträge und wirfst anschließend das überflüssige XML weg. Leite anschließend die Ausgabe in die Datei `users.txt` um, so dass Du jedem Eintrag den entsprechenden Git-Benutzer zuordnen kannst.
<!--You can provide this file to `git svn` to help it map the author data more accurately. You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `-\-no-metadata` to the `clone` or `init` command. This makes your `import` command look like this:-->
View
4 en/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installing on Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
5 en/02-git-basics/01-chapter2.markdown
@@ -551,7 +551,7 @@ Table 2-1 lists some of the more useful options that format takes.
You may be wondering what the difference is between _author_ and _committer_. The _author_ is the person who originally wrote the patch, whereas the _committer_ is the person who last applied the patch. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in *Chapter 5*.
-The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository:
+The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see in our copy of the Grit project repository:
$ git log --pretty=format:"%h %s" --graph
* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -577,6 +577,7 @@ Those are only some simple output-formatting options to `git log` — there are
--relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
--graph Display an ASCII graph of the branch and merge history beside the log output.
--pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
+ --oneline A convenience option short for `--pretty=oneline --abbrev-commit`.
### Limiting Log Output ###
@@ -754,7 +755,7 @@ I’ve mentioned and given some demonstrations of adding remote repositories in
origin git://github.com/schacon/ticgit.git
pb git://github.com/paulboone/ticgit.git
-Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run git fetch pb:
+Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run `git fetch pb`:
$ git fetch pb
remote: Counting objects: 58, done.
View
49 en/04-git-server/01-chapter4.markdown
@@ -506,32 +506,31 @@ If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[git
## Gitolite ##
-This section serves as a quick introduction to gitolite, and provides basic installation and setup instructions. It cannot, however, replace the enormous amount of [documentation][gltoc] that gitolite comes with. There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
+This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with. There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
[gldpg]: http://sitaramc.github.com/gitolite/progit.html
[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
-Gitolite is an authorisation layer on top of git, relying on sshd or httpd for authentication. (Recap: authentication is identifying who the user is, authorisation is deciding if he is allowed to do what he is attempting to).
+Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others.
### Installing ###
-Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind. You do not need root access, assuming git, perl, and an openssh compatible ssh server are already installed. In the examples below, we will use the `git` account on a host called `gitserver`.
+Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind. You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed. In the examples below, we will use the `git` account on a host called `gitserver`.
-Gitolite is somewhat unusual as far as "server" software goes -- access is via ssh, and so every userid on the server is a potential "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
+Gitolite is somewhat unusual as far as "server" software goes access is via SSH, and so every userid on the server is a potential "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
-To begin, create a user called `git` on your server and login to this user. Copy your ssh pubkey (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `YourName.pub`. Then run these commands:
+To begin, create a user called `git` on your server and login to this user. Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples). Then run these commands:
- git clone git://github.com/sitaramc/gitolite
- gitolite/install -ln
- # assumes $HOME/bin exists and is in your $PATH
- gitolite setup -pk $HOME/YourName.pub
- # for example, I would run 'gitolite setup -pk $HOME/sitaram.pub'
+ $ git clone git://github.com/sitaramc/gitolite
+ $ gitolite/install -ln
+ # assumes $HOME/bin exists and is in your $PATH
+ $ gitolite setup -pk $HOME/scott.pub
-Finally, back on your workstation, run `git clone git@server:gitolite-admin`.
+That last command creates new Git repository called `gitolite-admin` on the server.
-And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your gitolite setup by making changes to this repository and pushing.
+Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your Gitolite setup by making changes to this repository and pushing.
### Customising the Install ###
@@ -546,28 +545,28 @@ Once the install is done, you switch to the `gitolite-admin` clone you just made
conf/ keydir/
$ find conf keydir -type f
conf/gitolite.conf
- keydir/sitaram.pub
+ keydir/scott.pub
$ cat conf/gitolite.conf
repo gitolite-admin
- RW+ = sitaram
+ RW+ = scott
repo testing
RW+ = @all
-Notice that "sitaram" (the name of the pubkey in the gl-setup command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
+Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
-Adding users is easy. To add a user called "alice", obtain her public key, name it "alice.pub", and put it in the "keydir" directory of the clone of the gitolite-admin repo you just made on your workstation. Add, commit, and push the change, and the user has been added.
+Adding users is easy. To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation. Add, commit, and push the change, and the user has been added.
-The config file syntax for gitolite is well documented, so we’ll only mention some highlights here.
+The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here.
You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
@oss_repos = linux perl rakudo git gitolite
@secret_repos = fenestra pear
- @admins = scott # Adams, not Chacon, sorry :)
- @interns = ashok # get the spelling right, Scott!
+ @admins = scott
+ @interns = ashok
@engineers = sitaram dilbert wally alice
@staff = @admins @engineers @interns
@@ -610,20 +609,20 @@ Again, you simply follow the rules top down until you hit a match for your acces
### Restricting pushes by files changed ###
-In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell gitolite:
+In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell Gitolite:
repo foo
RW = @junior_devs @senior_devs
- VREF/NAME/Makefile = @junior_devs
-User who are migrating from the older gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
+User who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
### Personal Branches ###
Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
-A lot of code exchange in the git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
+A lot of code exchange in the Git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
@@ -631,17 +630,17 @@ Gitolite lets you define a "personal" or "scratch" namespace prefix for each dev
### "Wildcard" repositories ###
-Gitolite allows you to specify repositories with wildcards (actually perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. It also allows you to assign a new permission mode ("C") which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out R and RW permissions to other users to collaborate, etc. Again, please see the documentation for details.
+Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc. Again, please see the documentation for details.
### Other Features ###
We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation.
-**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away "master", the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
+**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here’s an example:
- hello sitaram, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+ hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
R anu-wsd
R entrans
View
2  en/08-git-and-other-scms/01-chapter8.markdown
@@ -363,7 +363,7 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
$ svn log --xml | grep -P "^<author" | sort -u | \
- perl -pe 's/<author>(.*?)<\/author>/$1 = /'
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 eo/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installing on Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
257 es-mx/01-introduction/01-chapter1.markdown
@@ -1,257 +0,0 @@
-# Getting Started #
-
-This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
-
-## About Version Control ##
-
-What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
-
-If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
-
-### Local Version Control Systems ###
-
-Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
-
-To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1).
-
-Insert 18333fig0101.png
-Figure 1-1. Local version control diagram.
-
-One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
-
-### Centralized Version Control Systems ###
-
-The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).
-
-Insert 18333fig0102.png
-Figure 1-2. Centralized version control diagram.
-
-This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
-
-However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
-
-### Distributed Version Control Systems ###
-
-This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).
-
-Insert 18333fig0103.png
-Figure 1-3. Distributed version control diagram.
-
-Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
-
-## A Short History of Git ##
-
-As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
-
-In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
-
-* Speed
-* Simple design
-* Strong support for non-linear development (thousands of parallel branches)
-* Fully distributed
-* Able to handle large projects like the Linux kernel efficiently (speed and data size)
-
-Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3).
-
-## Git Basics ##
-
-So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.
-
-### Snapshots, Not Differences ###
-
-The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4.
-
-Insert 18333fig0104.png
-Figure 1-4. Other systems tend to store data as changes to a base version of each file.
-
-Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5.
-
-Insert 18333fig0105.png
-Figure 1-5. Git stores data as snapshots of the project over time.
-
-This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3.
-
-### Nearly Every Operation Is Local ###
-
-Most operations in Git only need local files and resources to operate – generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
-
-For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
-
-This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.
-
-### Git Has Integrity ###
-
-Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it.
-
-The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
-
- 24b9da6552252987aa493b52f8696cd6d3b00373
-
-You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents.
-
-### Git Generally Only Adds Data ###
-
-When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
-
-This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see “Under the Covers” in Chapter 9.
-
-### The Three States ###
-
-Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
-
-This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
-
-Insert 18333fig0106.png
-Figure 1-6. Working directory, staging area, and git directory.
-
-The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
-
-The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
-
-The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
-
-The basic Git workflow goes something like this:
-
-1. You modify files in your working directory.
-2. You stage the files, adding snapshots of them to your staging area.
-3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
-
-If a particular version of a file is in the git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.
-
-## Installing Git ##
-
-Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform.
-
-### Installing from Source ###
-
-If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.
-
-To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
-
- $ yum install curl-devel expat-devel gettext-devel \
- openssl-devel zlib-devel
-
- $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
- libz-dev
-
-When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site:
-
- http://git-scm.com/download
-
-Then, compile and install:
-
- $ tar -zxf git-1.6.0.5.tar.gz
- $ cd git-1.6.0.5
- $ make prefix=/usr/local all
- $ sudo make prefix=/usr/local install
-
-After this is done, you can also get Git via Git itself for updates:
-
- $ git clone git://git.kernel.org/pub/scm/git/git.git
-
-### Installing on Linux ###
-
-If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
-
- $ yum install git-core
-
-Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
-
- $ apt-get install git
-
-### Installing on Mac ###
-
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
-
- http://code.google.com/p/git-osx-installer
-
-Insert 18333fig0107.png
-Figure 1-7. Git OS X installer.
-
-The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
-
- $ sudo port install git-core +svn +doc +bash_completion +gitweb
-
-You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
-
-### Installing on Windows ###
-
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
-
- http://code.google.com/p/msysgit
-
-After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
-
-## First-Time Git Setup ##
-
-Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
-
-Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
-
-* `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
-* `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
-* config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
-
-On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Documents and Settings\$USER` for most people). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
-
-### Your Identity ###
-
-The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:
-
- $ git config --global user.name "John Doe"
- $ git config --global user.email johndoe@example.com
-
-Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project.
-
-### Your Editor ###
-
-Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
-
- $ git config --global core.editor emacs
-
-### Your Diff Tool ###
-
-Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff:
-
- $ git config --global merge.tool vimdiff
-
-Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.
-
-### Checking Your Settings ###
-
-If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
-
- $ git config --list
- user.name=Scott Chacon
- user.email=schacon@gmail.com
- color.status=auto
- color.branch=auto
- color.interactive=auto
- color.diff=auto
- ...
-
-You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees.
-
-You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
-
- $ git config user.name
- Scott Chacon
-
-## Getting Help ##
-
-If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands:
-
- $ git help <verb>
- $ git <verb> --help
- $ man git-<verb>
-
-For example, you can get the manpage help for the config command by running
-
- $ git help config
-
-These commands are nice because you can access them anywhere, even offline.
-If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
-
-## Summary ##
-
-You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics.
View
4 es-ni/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installing on Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
2  es-ni/03-git-branching/01-chapter3.markdown
@@ -315,7 +315,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch merged`:
+Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
$ git branch --merged
iss53
View
3  es-ni/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 es/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ No necesitas añadir todos los extras, pero probablemente quieras incluir +svn e
### Instalando en Windows ###
-Instalar Git en Windows es muy fácil. El proyecto msysGit tiene uno de los procesos de instalación más sencillos. Simplemente descarga el archivo exe del instalador desde la página de Google Code, y ejecútalo:
+Instalar Git en Windows es muy fácil. El proyecto msysGit tiene uno de los procesos de instalación más sencillos. Simplemente descarga el archivo exe del instalador desde la página de GitHub, y ejecútalo:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Una vez instalado, tendrás tanto la versión de línea de comandos (incluido un cliente SSH que nos será útil más adelante) como la interfaz gráfica de usuario estándar.
View
3  es/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 fi/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Sinun ei tarvitse asentaa kaikkia ekstroista, mutta varmaankin haluat sisältä
### Asennus Windowsilla ###
-Gitin asennus Windowsilla on erittäin helppoa. msysGit projektilla on yksi helpoimmista asennusmenetelmistä. Yksinkertaisesti lataa asennus exe tiedosto Googlen Code verkkosivuilta ja suorita se:
+Gitin asennus Windowsilla on erittäin helppoa. msysGit projektilla on yksi helpoimmista asennusmenetelmistä. Yksinkertaisesti lataa asennus exe tiedosto GitHub verkkosivuilta ja suorita se:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Asennuksen jälkeen, sinulla on kummatkin, komentorivi versio (sisältäen SSH-asiakasohjelman, joka osoittautuu hyödylliseksi myöhemmin) ja standardi graafinen käyttöliittymä.
View
6 fr/01-introduction/01-chapter1.markdown
@@ -11,7 +11,7 @@ Un gestionnaire de version est un système qui enregistre l'évolution d'un fich
Dans les exemples de ce livre, nous utiliserons des fichiers sources de logiciel comme fichiers sous gestion de version, bien qu'en réalité on puisse l'utiliser avec pratiquement tous les types de fichiers d'un ordinateur.
Si vous êtes un dessinateur ou un développeur web, et que vous voulez conserver toutes les versions d'une image ou d'une mise en page (ce que vous souhaiteriez assurément), un système de gestion de version (VCS en anglais pour *Version Control System*) est un outil qu'il est très sage d'utiliser.
-Il vous permet de ramener un fichier à un état précédent, de ramener le projet complet à un état précédent, de comparer les changements au cours du temps, de voir qui a modifié quelque chose qui pourrait causer un problème, qui a introduit un problème et quand, et plus encore.
+Il vous permet de ramener un fichier à un état précédent, de ramener le projet complet à un état précédent, de visualiser les changements au cours du temps, de voir qui a modifié quelque chose qui pourrait causer un problème, qui a introduit un problème et quand, et plus encore.
Utiliser un VCS signifie aussi généralement que si vous vous trompez ou que vous perdez des fichiers, vous pouvez facilement revenir à un état stable.
De plus, vous obtenez tous ces avantages avec peu de travail additionnel.
@@ -266,9 +266,9 @@ Vous n'avez pas à ajouter tous les extras, mais vous souhaiterez sûrement incl
Installer Git sur Windows est très facile.
Le projet msysGit fournit une des procédures d'installation les plus simples.
-Téléchargez simplement le fichier exe d'installateur depuis la page Google Code, et lancez-le :
+Téléchargez simplement le fichier exe d'installateur depuis la page GitHub, et lancez-le :
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Après son installation, vous avez à la fois la version en ligne de commande (avec un client SSH utile pour la suite) et l'interface graphique standard.
View
3  fr/02-git-basics/01-chapter2.markdown
@@ -441,7 +441,7 @@ Si vous avez auparavant modifié et indexé le fichier, son élimination doit ê
C'est une mesure de sécurité pour empêcher un effacement accidentel de données qui n'ont pas encore été enregistrées dans un instantané et qui seraient définitivement perdues.
Un autre scénario serait de vouloir abandonner le suivi de version d'un fichier tout en le conservant dans la copie de travail.
-Ceci est particulièrement utile lorsqu'on a oublié de spécifier un patron dans le fichier `.gitignore` et on a accidentellement ajouté un fichier dans l'instantané, tel qu'un gros fichier de journal ou une série d'archives de compilation `.a`.
+Ceci est particulièrement utile lorsqu'on a oublié de spécifier un patron dans le fichier `.gitignore` et on a accidentellement indexé un fichier, tel qu'un gros fichier de journal ou une série d'archives de compilation `.a`.
Pour réaliser ce scénario, utilisez l'option `--cached` :
$ git rm --cached readme.txt
@@ -683,6 +683,7 @@ Le tableau 2-2 donne une liste des options que nous avons traitées ainsi que d'
--relative-date Affiche la date en format relatif (par exemple "2 weeks ago" : il y a deux semaines) au lieu du format de date complet
--graph Affiche en caractères ASCII le graphe de branches et fusions en vis-à-vis de l'historique
--pretty=<format> Affiche les *commits* dans un format alternatif. Les formats incluent `oneline`, `short`, `full`, `fuller`, et `format` (où on peut spécifier son propre format)
+ --oneline Option de convenance correspondant à `--pretty=oneline --abbrev-commit`
### Limiter la longueur de l'historique ###
View
30 fr/04-git-server/01-chapter4.markdown
@@ -685,7 +685,7 @@ Il se peut qu'elle subisse aussi occasionnellement quelques corrections qui sont
[gldpg]: http://sitaramc.github.com/gitolite/progit.html
[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
-Gitolite est une couche de gestion d'accès posée au dessus de Git, reposant sur sshd et httpd pour l'authentification.
+Gitolite est une couche de gestion d'accès posée au dessus de Git, reposant sur `sshd` et `httpd` pour l'authentification.
L'authentification consiste à identifier l'utilisateur, la gestion d'accès permet de décider si celui-ci est autorisé à accomplir ce qu'il s'apprête à faire.
### Installation ###
@@ -696,20 +696,20 @@ Vous n'avez pas besoin d'accès root si Git, Perl et un serveur compatible OpenS
Dans les exemples qui suivent, un compte `git` sur un serveur `gitserver` sera utilisé.
Pour commencer, créez un utilisateur nommé `git` et loggez-vous avec cet utilisateur.
-Copiez votre clé publique SSH depuis votre station de travail en la renommant `VotreNom.pub`.
+Copiez votre clé publique SSH depuis votre station de travail en la renommant `<votrenom>.pub` (nous utiliserons `scott.pub` pour l'exemple de cette section).
Ensuite, lancez les commandes ci-dessous :
- git clone git://github.com/sitaramc/gitolite
- gitolite/install -ln
+ $ git clone git://github.com/sitaramc/gitolite
+ $ gitolite/install -ln
# suppose que $HOME/bin existe et apparaît dans $PATH
- gitolite setup -pk $HOME/VotreNom.pub
- # Par exemple, je lancerais 'gitolite setup -pk $HOME/sitaram.pub'
+ $ gitolite setup -pk $HOME/scott.pub
-Enfin, de retour sur la station de travail, lancez `git clone git@gitserver:gitolite-admin`.
+Cette dernière commande crée un nouveau dépôt Git appelé `gitolite-admin` sur le serveur.
+Enfin, de retour sur la station de travail, lancez `git clone git@gitserver:gitolite-admin`.
C'est fini !
Gitolite est à présent installé sur le serveur ainsi qu'un nouveau dépôt appelé `gitolite-admin` qui a été cloné sur la station de travail.
-L'administration de gitolite passe par des modifications dans ce dépôt suivies d'une poussée sur le serveur.
+L'administration de Gitolite passe par des modifications dans ce dépôt suivies d'une poussée sur le serveur.
### Personnalisation de l'installation ###
@@ -726,16 +726,16 @@ Une fois l'installation terminée, vous pouvez basculer vers le clone `gitolite-
conf/ keydir/
$ find conf keydir -type f
conf/gitolite.conf
- keydir/sitaram.pub
+ keydir/scott.pub
$ cat conf/gitolite.conf
repo gitolite-admin
- RW+ = sitaram
+ RW+ = scott
repo testing
RW+ = @all
-Notez que « sitaram » (le nom de la clé publique pour la commande `gl-setup` ci-dessus) détient les permissions en lecture/écriture sur le dépôt `gitolite-admin` ainsi qu'une clé publique du même nom.
+Notez que « scott » (le nom de la clé publique pour la commande `gl-setup` ci-dessus) détient les permissions en lecture/écriture sur le dépôt `gitolite-admin` ainsi qu'une clé publique du même nom.
L'ajout d'utilisateurs est simple.
Pour ajouter une utilisatrice appelée « alice », demandez-lui de vous fournir une clé publique SSH, renommez-la `alice.pub`, et placez-la dans le répertoire `keydir` du clone du dépôt `gitolite-admin` sur la station de travail.
@@ -752,8 +752,8 @@ Cette distinction ne sert que lors de *l'utilisation* de la « macro ».
@oss_repos = linux perl rakudo git gitolite
@secret_repos = fenestra pear
- @admins = scott # Adams, not Chacon, sorry :)
- @interns = ashok # get the spelling right, Scott!
+ @admins = scott
+ @interns = ashok
@engineers = sitaram dilbert wally alice
@staff = @admins @engineers @interns
@@ -845,7 +845,7 @@ Référez-vous à la documentation pour plus de détails.
### Dépôts « joker » ###
Gitolite permet de spécifier des dépôts avec jokers (en fait des regex Perl), comme par exemple, au hasard, `devoirs/s[0-9][0-9]/a[0-9][0-9]`.
-Un nouveau mode de permission devient accessible (« C »).
+Un nouveau mode de permission devient accessible (`C`).
En suivant ces schémas de nommage, les utilisateurs peuvent alors créer des dépôts dont ils seront automatiquement propriétaires, leur permettant ainsi de leur assigner des droits en lecture ou lecture/écriture pour d'autres utilisateurs avec lesquels ils souhaitent collaborer.
Référez-vous à la documentation pour plus de détail.
@@ -860,7 +860,7 @@ Si vous étiez réticent à donner aux utilisateurs des droits de rembobiner (`R
Gitolite vous affiche à quels dépôts vous pouvez accéder et avec quels droits.
Ci-dessous un exemple :
- hello sitaram, this is git@git running gitolite3 \
+ hello scott, this is git@git running gitolite3 \
v3.01-18-g9609868 on git 1.7.4.4
R anu-wsd
View
2  fr/07-customizing-git/01-chapter7.markdown
@@ -521,7 +521,7 @@ Si vous remplacez une image dans votre projet et lancez `git diff`, vous verrez
@@ -1,12 +1,12 @@
ExifTool Version Number : 7.74
-File Size : 70 kB
- -File Modification Date/Time : 2009:04:21 07:02:45-07:00
+ -File Modification Date/Time : 2009:04:17 10:12:35-07:00
+File Size : 94 kB
+File Modification Date/Time : 2009:04:21 07:02:43-07:00
File Type : PNG
View
10 fr/08-git-and-other-scms/01-chapter8.markdown
@@ -446,7 +446,7 @@ Créez un fichier appelé `users.txt` contenant cette équivalence dans le forma
Pour récupérer la liste des noms d'auteurs utilisés par SVN, vous pouvez utiliser la ligne suivante :
$ svn log --xml | grep -P "^<author" | sort -u | \
- perl -pe 's/<author>(.*?)<\/author>/$1 = /'
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
Cela génère une sortie au format XML — vous pouvez visualiser les auteurs, créer une liste unique puis éliminer l'XML.
Évidemment, cette ligne ne fonctionne que sur une machine disposant des commandes `grep`, `sort` et `perl`.
@@ -509,9 +509,9 @@ Toutes vos données, branches et tags sont à présent disponibles sur le serveu
### Perforce ###
L'autre système duquel on peut souhaiter importer les données est Perforce.
-Un outil d'import Perforce est aussi distribué avec Git, mais seulement dans la section `contrib` du code source.
-Il n'est pas disponible par défaut comme `git svn`.
-Pour le lancer, il vous faut récupérer le code source de Git que vous pouvez télécharger à partir de `git.kernel.org` :
+Un outil d'import Perforce est aussi distribué avec Git.
+Si votre version de Git est antérieures à 1.7.11, celui-ci n'est disponible que dans la section `contrib` du code source.
+Dans ce dernier cas, pour le lancer, il vous faut récupérer le code source de Git que vous pouvez télécharger à partir de `git.kernel.org` :
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git/contrib/fast-import
@@ -764,7 +764,7 @@ Si vous lancez ce script, vous obtiendrez un contenu qui ressemble à ceci :
new version one
(...)
-Pour lancer l'outil d'import, redirigez cette sortie dans `git fast-import` alors que vous vous trouvez dans le répertoire Git dans lequel vous souhaitez importer.
+Pour lancer l'outil d'import, redirigez cette sortie dans `git fast-import` alors que vous vous trouvez dans le projet Git dans lequel vous souhaitez importer.
Vous pouvez créer un nouveau répertoire, puis l'initialiser avec `git init`, puis lancer votre script :
$ git init
View
4 hu/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installing on Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
4 id/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Anda tidak harus menambahkan extras-nya, tetapi anda mungkin membutuhkan +svn ji
### Menginstall pada Sistem Operasi Windows ###
-Menginstall Git pada Windows sangatlah mudah. Cara termudah dapat anda peroleh dengan menggunakan msysGit. Cukup download file installernya dari halaman Google Code, lalu eksekusi.
+Menginstall Git pada Windows sangatlah mudah. Cara termudah dapat anda peroleh dengan menggunakan msysGit. Cukup download file installernya dari halaman GitHub, lalu eksekusi.
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Setelah terinstall, anda akan memperoleh versi command-line (bersama dengan klien SSH yang praktis) dan versi GUI-nya.
View
4 it/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Non ti occorre aggiungere tutti i pacchetti, ma evidentemente vorrai includere +
### Installazione su Windows ###
-Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione tra le più facili. Semplicemente scarica l'installatore exe dalla pagina di Google Code, e lancialo:
+Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione tra le più facili. Semplicemente scarica l'installatore exe dalla pagina di GitHub, e lancialo:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Una volta installato, hai a disposizione sia la versione da riga di comando (incluso un client SSH che sarà utile, in seguito) sia l'interfaccia grafica (GUI) standard.
View
4 ja/01-introduction/01-chapter1.markdown
@@ -178,9 +178,9 @@ Insert 18333fig0107.png
### Windowsにインストール ###
-WindowsにGitをインストールするのはとても簡単です。msysGitプロジェクトは、より簡単なインストール手続きの一つを備えています。Google Codeのページから、単純にインストーラーのexeファイルをダウンロードをし、実行してください:
+WindowsにGitをインストールするのはとても簡単です。msysGitプロジェクトは、より簡単なインストール手続きの一つを備えています。GitHubのページから、単純にインストーラーのexeファイルをダウンロードをし、実行してください:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
インストール後、コマンドライン版(後で役に立つSSHクライアントを含む)とスタンダードGUI版の両方を使う事ができます。
View
2  ja/03-git-branching/01-chapter3.markdown
@@ -314,7 +314,7 @@ Git は新たなマージコミットを自動的には作成しませんでし
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
-各ブランチの状態を知るために便利なもうひとつの機能として、現在作業中のブランチにマージ済みかそうでないかによる絞り込みができるようになっています。そのための便利なオプション `--merged``--no-merged` が、Git バージョン 1.5.6 以降で使用可能となりました。現在作業中のブランチにマージ済みのブランチを調べるには `git branch merged` を実行します。
+各ブランチの状態を知るために便利なもうひとつの機能として、現在作業中のブランチにマージ済みかそうでないかによる絞り込みができるようになっています。そのための便利なオプション `--merged``--no-merged` が、Git バージョン 1.5.6 以降で使用可能となりました。現在作業中のブランチにマージ済みのブランチを調べるには `git branch --merged` を実行します。
$ git branch --merged
iss53
View
3  ja/08-git-and-other-scms/01-chapter8.markdown
@@ -363,7 +363,8 @@ Subversion に慣れているので SVN が出力する形式で歴史を見た
SVN で使っている作者の一覧を取得するには、このようにします。
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
これは、まずログを XML フォーマットで出力します。その中から作者を捜して重複を省き、XML を除去します (ちょっと見ればわかりますが、これは `grep` や `sort`、そして `perl` といったコマンドが使える環境でないと動きません)。この出力を users.txt にリダイレクトし、そこに Git のユーザーデータを書き足していきます。
View
2  ko/01-introduction/01-chapter1.markdown
@@ -178,7 +178,7 @@ MacPorts(`http://www.macports.org`)를 사용하는 방법도 있다. MacPorts
Git을 윈도우에 설치하기도 쉽다. 그저 구글 코드 페이지에서 msysGit 인스톨러를 내려받고 실행하면 된다:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
설치가 완료되면 CLI 프로그램과 GUI 프로그램을 둘 다 사용할 수 있다. CLI 프로그램에는 SSH 클라이언트가 포함돼 있기 때문에 유용하다.
View
3  ko/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ Subversion 저장소를 클론하면 쓸데 없는 파일을 커밋하지 않도
SVN에 기록된 Author 이름은 어떤 것들이 있는지 다음 명령으로 조회한다:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
우선 XML 형식으로 SVN 로그를 출력하고, 거기서 Author 정보만 찾고, 중복된 것을 제거하고, XML Tag는 버린다. 물론 `grep`, `sort`, `perl` 명령이 동작하는 시스템에서만 이 명령을 사용할 수 있다. 이 결과에 Git Author 정보를 더해서 `users.txt` 만든다.
View
15 latex/makepdf
@@ -10,16 +10,25 @@ $here = File.expand_path(File.dirname(__FILE__))
$root = File.join($here, '..')
$outDir = File.join($root, 'pdf')
-def figures(&block)
+def figures(lang,&block)
begin
Dir["#$root/figures/18333*.png"].each do |file|
cp(file, file.sub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
end
+ Dir["#$root/#{lang}/figures-dia/*.dia"].each do |file|
+ eps_dest= file.sub(/.*fig0(\d)0?(\d+).dia/, '\1.\2.eps')
+ system("dia -t eps-pango -e #$root/figures/#{eps_dest} #{file}")
+ system("epstopdf #$root/figures/#{eps_dest}")
+ end
+ cp(Dir["#$root/#{lang}/figures/*.png"],"#$root/figures")
+ cp(Dir["#$root/#{lang}/figures/*.pdf"],"#$root/figures")
block.call
ensure
Dir["#$root/figures/18333*.png"].each do |file|
rm(file.gsub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
end
+ rm(Dir["#$root/figures/*.pdf"])
+ rm(Dir["#$root/figures/*.eps"])
end
end
@@ -142,8 +151,8 @@ unless missing.empty?
exit
end
-figures do
- languages.each do |lang|
+languages.each do |lang|
+ figures(lang) do
config = $config['default'].merge($config[lang]) rescue $config['default']
puts "#{lang}:"
View
3  latex/template.tex
@@ -89,7 +89,8 @@
\newcommand{\img}[1]{\begin{figure}[ht!]
\refstepcounter{img}
\label{img:\theimg}
- \centering\includegraphics[width=\maxwidth]{figures/\theimg.png}
+ \centering\IfFileExists{figures/\theimg.pdf}{\includegraphics[width=\maxwidth]{figures/\theimg.pdf}}{\includegraphics[width=\maxwidth]{figures/\theimg.png}}
+
\textbf{\caption{#1}}
\end{figure}}
View
117 makeebooks
@@ -15,6 +15,29 @@
require 'rubygems'
require 'rdiscount'
+require 'fileutils'
+include FileUtils
+
+def figures(lang,&block)
+ begin
+ Dir["figures/18333*.png"].each do |file|
+ cp(file, file.sub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
+ end
+ Dir["#{lang}/figures/*.png"].each do |file|
+ cp(file,"figures")
+ end
+ Dir["#{lang}/figures-dia/*.dia"].each do |file|
+ png_dest= file.sub(/.*fig0(\d)0?(\d+).dia/, 'figures/\1.\2.png')
+ system("dia -e #{png_dest} #{file}")
+ end
+ block.call
+ ensure
+ Dir["figures/18333*.png"].each do |file|
+ rm(file.gsub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
+ end
+ end
+end
+
if ARGV.length == 0
puts "you need to specify at least one language. For example: makeebooks en"
@@ -25,54 +48,56 @@ format = ENV['FORMAT'] || 'mobi'
puts "using .#{format} (you can change it via FORMAT environment variable. try 'mobi' or 'epub')"
ARGV.each do |lang|
- puts "convert content for '#{lang}' language"
+ figures (lang) do
+ puts "convert content for '#{lang}' language"
- figure_title = 'Figure'
- book_title = 'Pro Git - professional version control'
- authors = 'Scott Chacon'
- comments = 'licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
- if lang == 'ko'
- figure_title = '그림'
- elsif lang == 'ja'
- figure_title = ''
- elsif lang == 'ru'
- figure_title = 'Рисунок'
- book_title = 'Pro Git — профессиональный контроль версий'
- authors = 'Скот Чакон'
- comments = 'Лицензия: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
- elsif lang == 'es'
- figure_title = 'Figura'
- elsif lang == 'it'
- figure_title = 'Figura'
- comments = 'distribuito sotto licenza Creative Commons Attribution-Non Commercial-Share Alike 3.0'
- elsif lang == 'zh'
- figure_title = ''
- elsif lang == 'zh-tw'
- figure_title = ''
- elsif lang == 'pt-br'
- figure_title = 'Figura'
- end
+ figure_title = 'Figure'
+ book_title = 'Pro Git - professional version control'
+ authors = 'Scott Chacon'
+ comments = 'licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+ if lang == 'ko'
+ figure_title = '그림'
+ elsif lang == 'ja'
+ figure_title = ''
+ elsif lang == 'ru'
+ figure_title = 'Рисунок'
+ book_title = 'Pro Git — профессиональный контроль версий'
+ authors = 'Скот Чакон'
+ comments = 'Лицензия: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+ elsif lang == 'es'
+ figure_title = 'Figura'
+ elsif lang == 'it'
+ figure_title = 'Figura'
+ comments = 'distribuito sotto licenza Creative Commons Attribution-Non Commercial-Share Alike 3.0'
+ elsif lang == 'zh'
+ figure_title = ''
+ elsif lang == 'zh-tw'
+ figure_title = ''
+ elsif lang == 'pt-br'
+ figure_title = 'Figura'
+ end
- book_content = %(<html xmlns="http://www.w3.org/1999/xhtml"><head><title>#{book_title}</title></head><body>)
- dir = File.expand_path(File.join(File.dirname(__FILE__), lang))
- Dir[File.join(dir, '**', '*.markdown')].sort.each do |input|
- puts "processing #{input}"
- content = File.read(input)
- content.gsub!(/Insert\s+(.*)(\.png)\s*\n?\s*#{figure_title}\s*(.*)/, '![\3](figures/\1-tn\2 "\3")')
- book_content << RDiscount.new(content).to_html
- end
- book_content << "</body></html>"
+ book_content = %(<html xmlns="http://www.w3.org/1999/xhtml"><head><title>#{book_title}</title></head><body>)
+ dir = File.expand_path(File.join(File.dirname(__FILE__), lang))
+ Dir[File.join(dir, '**', '*.markdown')].sort.each do |input|
+ puts "processing #{input}"
+ content = File.read(input)
+ content.gsub!(/Insert\s18333fig\d+\.png\s*\n.*?(\d{1,2})-(\d{1,2})\. (.*)/, '![\1.\2 \3](figures/\1.\2.png "\1.\2 \3")')
+ book_content << RDiscount.new(content).to_html
+ end
+ book_content << "</body></html>"
- File.open("progit.#{lang}.html", 'w') do |output|
- output.write(book_content)
- end
+ File.open("progit.#{lang}.html", 'w') do |output|
+ output.write(book_content)
+ end
- system('ebook-convert', "progit.#{lang}.html", "progit.#{lang}.#{format}",
- '--cover', 'ebooks/cover.png',
- '--authors', authors,
- '--comments', comments,
- '--level1-toc', '//h:h1',
- '--level2-toc', '//h:h2',
- '--level3-toc', '//h:h3',
- '--language', lang)
+ system('ebook-convert', "progit.#{lang}.html", "progit.#{lang}.#{format}",
+ '--cover', 'ebooks/cover.png',
+ '--authors', authors,
+ '--comments', comments,
+ '--level1-toc', '//h:h1',
+ '--level2-toc', '//h:h2',
+ '--level3-toc', '//h:h3',
+ '--language', lang)
+ end
end
View
4 mk/01-introduction/01-chapter1.markdown
@@ -177,9 +177,9 @@ Insert 18333fig0107.png
### Инсталирање на Windows ###
-Инсталирањето на Git на Windows е многу едноставно. msysGit проектот има еден од најлесните инсталациски процедури. Едноставно симнете го инсталерот од Google Code страната, и стартувајте го:
+Инсталирањето на Git на Windows е многу едноставно. msysGit проектот има еден од најлесните инсталациски процедури. Едноставно симнете го инсталерот од GitHub страната, и стартувајте го:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
По инсталацијата, ги имате и верзијата од командна линија (вклучувајќи SSH клиент кој што ќе ви се најде подоцна) и верзија со стандарден графички интерфејс.
View
2  mk/03-git-branching/01-chapter3.markdown
@@ -315,7 +315,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch merged`:
+Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
$ git branch --merged
iss53
View
3  mk/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 nl/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Je hoeft niet al die extra’s toe te voegen, maar je wilt waarschijnlijk +svn e
### Op Windows installeren ###
-Git op Windows installeren is erg eenvoudig. Het msysGit project heeft één van de eenvoudiger installatieprocedures. Je hoeft alleen maar het installatieprogramma te downloaden van Google Code, en het uit te voeren:
+Git op Windows installeren is erg eenvoudig. Het msysGit project heeft één van de eenvoudiger installatieprocedures. Je hoeft alleen maar het installatieprogramma te downloaden van GitHub, en het uit te voeren:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Nadat het geïnstalleerd is, kun je Git zowel vanaf de commandprompt gebruiken (waar ook een SSH client bijzit die later nog van pas zal komen) als via de standaard GUI.
View
3  nl/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ Maar, de import is niet perfect; en omdat het zo lang zal duren, kun je het maar
Om een lijst te krijgen van de auteurnamen, die SVN gebruikt kun je dit uitvoeren:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
Daarmee krijg je de log output in XML formaat – je kunt hierin zoeken naar de auteurs, een lijst met unieke vermeldingen creëren en dan de XML eruit halen. (Dit werkt natuurlijk alleen op een machine waarop `grep`, `sort` en `Perl` geïnstalleerd is.) Daarna stuur je die output naar je users.txt bestand zodat je de gelijkwaardige Git gebruiker data naast iedere vermelding kunt zetten.
View
4 no-nb/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ You don’t have to add all the extras, but you’ll probably want to include +s
### Installasjon på Windows ###
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
View
3  no-nb/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ However, the import isn’t perfect; and because it will take so long, you may a
To get a list of the author names that SVN uses, you can run this:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
That gives you the log output in XML format — you can look for the authors, create a unique list, and then strip out the XML. (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.) Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
View
4 pl/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Nie musisz instalować wszystkich dodatków, ale dobrym pomysłem jest dołącze
### Instalacja w systemie Windows ###
-Instalacja Git w systemie Windows jest bardzo prosta. Projekt msysGit posiada jedną z najprostszych procedur instalacji. Po prostu pobierz program instalatora z witryny Google Code i uruchom go:
+Instalacja Git w systemie Windows jest bardzo prosta. Projekt msysGit posiada jedną z najprostszych procedur instalacji. Po prostu pobierz program instalatora z witryny GitHub i uruchom go:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
Po instalacji masz dostęp zarówno do wersji konsolowej, uruchamianej z linii poleceń (w tym do klienta SSH, który przyda się jeszcze później) oraz do standardowego GUI.
View
2  pt-br/01-introduction/01-chapter1.markdown
@@ -176,7 +176,7 @@ Você não precisa adicionar todos os extras, mas você provavelmente irá quere
### Instalando no Windows ###
-Instalar o Git no Windows é muito fácil. O projeto msysgit tem um dos procedimentos mais simples de instalação. Simplesmente baixe o arquivo exe do instalador a partir da página do Google Code e execute-o:
+Instalar o Git no Windows é muito fácil. O projeto msysgit tem um dos procedimentos mais simples de instalação. Simplesmente baixe o arquivo exe do instalador a partir da página do GitHub e execute-o:
http://msysgit.github.com
View
3  pt-br/08-git-and-other-scms/01-chapter8.markdown
@@ -362,7 +362,8 @@ No entanto, a importação não é perfeita; e já que vai demorar tanto tempo,
Para obter uma lista dos nomes de autores que o SVN usa, você pode executar isto:
- $ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /'
+ $ svn log --xml | grep -P "^<author" | sort -u | \
+ perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
Isso te dá a saída do log em formato XML — você pode pesquisar pelos autores, criar uma lista única, e depois tirar o XML. (Obviamente isso só funciona em uma máquina com `grep`, `sort`, e `perl` instalados.) Em seguida, redirecione a saída em seu arquivo users.txt assim, você pode adicionar os dados de usuários do Git equivalentes ao lado de cada entrada.
View
4 ro/01-introduction/01-chapter1.markdown
@@ -176,9 +176,9 @@ Nu trebuie să adăugați toate extra-opțiunile, dar probabil veți dori să in
### Instalarea pe sistemele Windows ###
-Instalarea Git în Windows este foarte simplă. Proiectul msysGit are una din procedurile cele mai simple de instalare. Pur și simplu descărcați programul de instalare de pe pagina Google Code, și rulați-l:
+Instalarea Git în Windows este foarte simplă. Proiectul msysGit are una din procedurile cele mai simple de instalare. Pur și simplu descărcați programul de instalare de pe pagina GitHub, și rulați-l:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
După ce este instalat, veți avea atât o versiune în linie de comandă (inclusiv un client SSH care vă va fi util mai târziu) cât și o interfață grafică standard (GUI [en]).
View
20 ru/01-introduction/01-chapter1.markdown
@@ -17,7 +17,7 @@
Insert 18333fig0101.png
Рисунок 1-1. Схема локальной СКВ.
-Одной из наиболее популярных СКВ данного типа является rcs, которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на работе с наборами патчей между парами изменений (патч — файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.
+Одной из наиболее популярных СКВ такого типа является rcs, которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на работе с наборами патчей между парами версий (патч — файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.
### Централизованные системы контроля версий ###
@@ -120,13 +120,13 @@ Insert 18333fig0106.png
## Установка Git ##
-Настало время немного ознакомиться с использованием Git'а. Первое, что вам необходимо сделать, — установить его. Есть несколько способов сделать это; два основных установка из исходников и установка собранного пакета для вашей платформы.
+Настало время немного ознакомиться с использованием Git'а. Первое, что вам необходимо сделать, — установить его. Есть несколько способов сделать это; два основных установка из исходников и установка собранного пакета для вашей платформы.
### Установка из исходников ###
Если есть возможность, то, как правило, лучше установить Git из исходных кодов, поскольку так вы получите самую свежую версию. Каждая новая версия Git'а обычно включает полезные улучшения пользовательского интерфейса, поэтому получение последней версии — часто лучший путь, если, конечно, вас не затрудняет установка программ из исходников. К тому же, многие дистрибутивы Linux содержат очень старые пакеты. Поэтому, если только вы не на очень свежем дистрибутиве или используете пакеты из экспериментальной ветки, установка из исходников может быть самым выигрышным решением.
-Для установки Git'а вам понадобятся библиотеки, от которых он зависит: curl, zlib, openssl, expat и libiconv. Например, если в вашей системе менеджер пакетов yum (Fedora), или apt-get (Debian, Ubuntu), можно воспользоваться следующими командами, чтобы разрешить все зависимости:
+Для установки Git'а вам понадобятся библиотеки, от которых он зависит: curl, zlib, openssl, expat и libiconv. Например, если в вашей системе менеджер пакетов yum (Fedora), или apt-get (Debian, Ubuntu), можно воспользоваться следующими командами, чтобы разрешить все зависимости:
$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel
@@ -161,14 +161,14 @@ Insert 18333fig0106.png
### Установка на Mac ###
-Есть два простых способа установить Git на Mac. Самый простой использовать графический инсталлятор Git'а, который вы можете скачать со страницы на Google Code (см. рисунок 1-7):
+Есть два простых способа установить Git на Mac. Самый простой использовать графический инсталлятор Git'а, который вы можете скачать со страницы на Google Code (см. рисунок 1-7):
http://code.google.com/p/git-osx-installer
Insert 18333fig0107.png
Рисунок 1-7. Инсталлятор Git'а под OS X.
-Другой распространённый способ установки Git'а через MacPorts (`http://www.macports.org`). Если у вас установлен MacPorts, установите Git так:
+Другой распространённый способ установки Git'а через MacPorts (`http://www.macports.org`). Если у вас установлен MacPorts, установите Git так:
$ sudo port install git-core +svn +doc +bash_completion +gitweb
@@ -176,9 +176,9 @@ Insert 18333fig0107.png
### Установка в Windows ###
-Установить Git в Windows очень просто. У проекта msysGit процедура установки одна из самых простых. Просто скачайте exe-файл инсталлятора со страницы проекта на Google Code и запустите его:
+Установить Git в Windows очень просто. У проекта msysGit процедура установки одна из самых простых. Просто скачайте exe-файл инсталлятора со страницы проекта на GitHub'е и запустите его:
- http://code.google.com/p/msysgit
+ http://msysgit.github.com/
После установки у вас будет как консольная версия (включающая SSH-клиент, который пригодится позднее), так и стандартная графическая.
@@ -186,7 +186,7 @@ Insert 18333fig0107.png
## Первоначальная настройка Git ##
-Теперь, когда Git установлен в вашей системе, хотелось бы сделать кое-какие вещи, чтобы настроить среду для работы с Git'ом под себя. Это нужно сделать только один раз при обновлении версии Git'а настройки сохранятся. Но вы можете поменять их в любой момент, выполнив те же команды снова.
+Теперь, когда Git установлен в вашей системе, хотелось бы сделать кое-какие вещи, чтобы настроить среду для работы с Git'ом под себя. Это нужно сделать только один раз при обновлении версии Git'а настройки сохранятся. Но вы можете поменять их в любой момент, выполнив те же команды снова.
В состав Git'а входит утилита `git config`, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git'а и его внешний вид. Эти параметры могут быть сохранены в трёх местах:
@@ -198,7 +198,7 @@ Insert 18333fig0107.png
### Имя пользователя ###
-Первое, что вам следует сделать после установки Git'а, указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
+Первое, что вам следует сделать после установки Git'а, указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
@@ -213,7 +213,7 @@ Insert 18333fig0107.png
### Утилита сравнения ###
-Другая полезная настройка, которая может понадобиться встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:
+Другая полезная настройка, которая может понадобиться встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:
$ git config --global merge.tool vimdiff
View
14 ru/03-git-branching/01-chapter3.markdown
@@ -195,7 +195,7 @@ Insert 18333fig0315.png
### Основы слияния ###
-Допустим, вы разобрались с проблемой №53 и готовы объединить эту ветку и свой `master`. Чтобы сделать это, мы сольём ветку `iss53` в ветку `master` точно так же, как мы делали это ранее с веткой `hotfix`. Всё, что вам нужно сделать, перейти на ту ветку, в которую вы хотите слить свои изменения, и выполнить команду `git merge`:
+Допустим, вы разобрались с проблемой №53 и готовы объединить эту ветку и свой `master`. Чтобы сделать это, мы сольём ветку `iss53` в ветку `master` точно так же, как мы делали это ранее с веткой `hotfix`. Всё, что вам нужно сделать, перейти на ту ветку, в которую вы хотите слить свои изменения, и выполнить команду `git merge`:
$ git checkout master
$ git merge iss53
@@ -250,7 +250,7 @@ Git не создал новый коммит для слияния. Он при
</div>
>>>>>>> iss53:index.html
-В верхней части блока (всё что выше `=======`) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё, что находится в нижней части версия в `iss53`. Чтобы разрешить конфликт, вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Например, вы можете разрешить этот конфликт заменой всего блока, показанного выше, следующим блоком:
+В верхней части блока (всё что выше `=======`) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё, что находится в нижней части версия в `iss53`. Чтобы разрешить конфликт, вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Например, вы можете разрешить этот конфликт заменой всего блока, показанного выше, следующим блоком:
<div id="footer">
please contact us at email.support@github.com
@@ -270,7 +270,7 @@ Git не создал новый коммит для слияния. Он при
Если вы хотите использовать другой инструмент для слияния, нежели выбираемый по умолчанию (Git выбрал `opendiff` для меня, так как я выполнил команду на Mac'е). Вы можете увидеть все поддерживаемые инструменты, указанные выше после “merge tool candidates”. Укажите название предпочтительного для вас инструмента. В главе 7 мы обсудим, как изменить это значение по умолчанию для вашего окружения.
-После того как вы выйдете из инструмента для выполнения слияния, Git спросит вас, было ли оно успешным. Если вы отвечаете, что да файл индексируется (добавляется в область для коммита), чтобы дать вам понять, что конфликт разрешён.
+После того как вы выйдете из инструмента для выполнения слияния, Git спросит вас, было ли оно успешным. Если вы отвечаете, что да файл индексируется (добавляется в область для коммита), чтобы дать вам понять, что конфликт разрешён.
Можете выполнить `git status` ещё раз, чтобы убедиться, что все конфликты были разрешены:
@@ -356,12 +356,12 @@ Insert 18333fig0318.png
Insert 18333fig0319.png
Рисунок 3-19. Может быть полезным думать о ветках как о силосных башнях.
-Вы можете применять эту идею для нескольких разных уровней стабильности. Некоторые большие проекты также имеют ветку `proposed` или `pu` (proposed updates предлагаемые изменения), которые включают в себя ветки, не готовые для перехода в ветку `next` или `master`. Идея такова, что ваши ветки находятся на разных уровнях стабильности; когда они достигают более высокого уровня стабильности, они сливаются с веткой, стоящей на более высоком уровне.
+Вы можете применять эту идею для нескольких разных уровней стабильности. Некоторые большие проекты также имеют ветку `proposed` или `pu` (proposed updates предлагаемые изменения), которые включают в себя ветки, не готовые для перехода в ветку `next` или `master`. Идея такова, что ваши ветки находятся на разных уровнях стабильности; когда они достигают более высокого уровня стабильности, они сливаются с веткой, стоящей на более высоком уровне.
Опять-таки, иметь долгоживущие ветки не обязательно, но зачастую это полезно, особенно когда вы имеете дело с очень большими и сложными проектами.
### Тематические ветки ###
-Тематические ветки, однако, полезны в проектах любого размера. Тематическая ветка недолговечная ветка, которую вы создаёте и используете для работы над некоторой отдельной функциональностью или для вспомогательной работы. Это то, чего вы, вероятно, никогда не делали с системами контроля версий раньше, так как создание и слияние веток обычно слишком затратно. Но в Git'е принято создавать ветки, работать над ними, сливать и удалять их по несколько раз в день.
+Тематические ветки, однако, полезны в проектах любого размера. Тематическая ветка недолговечная ветка, которую вы создаёте и используете для работы над некоторой отдельной функциональностью или для вспомогательной работы. Это то, чего вы, вероятно, никогда не делали с системами контроля версий раньше, так как создание и слияние веток обычно слишком затратно. Но в Git'е принято создавать ветки, работать над ними, сливать и удалять их по несколько раз в день.
Мы видели подобное в последнем разделе, где вы создавали ветки `iss53` и `hotfix`. Вы сделали всего несколько коммитов на этих ветках и удалили их сразу же после слияния с основной веткой. Такая техника позволяет быстро и полноценно переключать контекст. Ибо когда все изменения разбиты по веткам и определённым темам, намного проще понять, что было сделано, во время проверки и просмотра кода. Вы можете сохранить там изменения на несколько минут, дней или месяцев, а затем, когда они готовы, слить их в основную ветку, независимо от порядка, в котором их создавали или работали над ними.
@@ -375,11 +375,11 @@ Insert 18333fig0320.png
Insert 18333fig0321.png
Рисунок 3-21. Ваша история после слияния dumbidea и iss91v2.
-Важно запомнить, что когда вы выполняете все эти действия, ветки являются полностью локальными. Когда вы выполняете ветвление и слияние, всё происходит только в вашем репозитории связь с сервером не осуществляется.
+Важно запомнить, что когда вы выполняете все эти действия, ветки являются полностью локальными. Когда вы выполняете ветвление и слияние, всё происходит только в вашем репозитории связь с сервером не осуществляется.
## Удалённые ветки ##
-Удалённые ветки это ссылки на состояние веток в ваших удалённых репозиториях. Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
+Удалённые ветки это ссылки на состояние веток в ваших удалённых репозиториях. Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
Они выглядят как `(имя удал. репоз.)/(ветка)`. Например, если вы хотите посмотреть, как выглядела ветка `master` на сервере `origin` во время последнего соединения с ним, проверьте ветку `origin/master`. Если вы с партнёром работали над одной проблемой, и он выложил ветку `iss53`, у вас может быть своя локальная ветка `iss53`; но та ветка на сервере будет указывать на коммит в `origin/iss53`.
View
129 ru/04-git-server/01-chapter4.markdown
@@ -1,12 +1,12 @@
# Git на сервере #
-К этому моменту вы уже должны уметь делать большую часть повседневных задач, для которых вы будете использовать Git. Однако, для совместной работы в Git'е, вам необходим удалённый репозиторий. Несмотря на то, что технически вы можете отправлять и забирать изменения непосредственно из личных репозиториев, делать это не рекомендуется. Вы легко можете испортить то, над чем работают другие, если не будете аккуратны. К тому же, вам бы наверняка хотелось, чтобы остальные имели доступ к репозиторию даже если ваш компьютер выключен, поэтому наличие более надежного репозитория обычно весьма полезно. Поэтому предпочтительный метод взаимодействия с кем-либо ― это создание промежуточного репозитория, к которому вы оба будете иметь доступ, и отправка и получение изменений через него. Мы будем называть этот репозиторий "Git-сервер", но обычно размещение Git-репозитория требует очень небольшого количества ресурсов, поэтому вряд ли вам для этого будет нужен весь сервер.
+К этому моменту вы уже должны уметь делать большую часть повседневных задач, для которых вы будете использовать Git. Однако, для совместной работы в Git'е, вам необходим удалённый репозиторий. Несмотря на то, что технически вы можете отправлять и забирать изменения непосредственно из личных репозиториев, делать это не рекомендуется. Вы легко можете испортить то, над чем работают другие, если не будете аккуратны. К тому же, вам бы наверняка хотелось, чтобы остальные имели доступ к репозиторию даже если ваш компьютер выключен, поэтому наличие более надежного репозитория обычно весьма полезно. Поэтому предпочтительный метод взаимодействия с кем-либо — это создание промежуточного репозитория, к которому вы оба будете иметь доступ, и отправка и получение изменений через него. Мы будем называть этот репозиторий "Git-сервер", но обычно размещение Git-репозитория требует очень небольшого количества ресурсов, поэтому вряд ли вам для этого будет нужен весь сервер.
Запустить Git-сервер просто. Для начала вам следует выбрать протокол, который вы будете использовать для связи с сервером. Первая часть этой главы описывает доступные протоколы и их достоинства и недостатки. Следующие части освещают базовые конфигурации с использованием этих протоколов, а также настройку вашего сервера для работы с ними. Наконец, мы рассмотрим несколько вариантов готового хостинга, если вы не против разместить ваш код на чьём-то сервере и вы не хотите мучиться с настройками и поддержкой вашего собственного сервера.
Если вас не интересует настройка собственного сервера, вы можете перейти сразу к последней части этой главы для настройки аккаунта на Git-хостинге, и затем перейти к следующей главе, где мы обсудим различные аспекты работы с распределённой системой контроля версий.
-Удалённый репозиторий — это обычно _голый (чистый, bare) репозиторий_ Git-репозиторий, не имеющий рабочего каталога. Поскольку этот репозиторий используется только для обмена, нет причин создавать рабочую копию на диске, и он содержит только данные Git'а. Проще говоря, голый репозиторий содержит только каталог `.git` вашего проекта и ничего больше.
+Удалённый репозиторий — это обычно _голый (чистый, bare) репозиторий_ Git-репозиторий, не имеющий рабочего каталога. Поскольку этот репозиторий используется только для обмена, нет причин создавать рабочую копию на диске, и он содержит только данные Git'а. Проще говоря, голый репозиторий содержит только каталог `.git` вашего проекта и ничего больше.
## Протоколы ##
@@ -16,7 +16,7 @@ Git умеет работать с четырьмя сетевыми прото
### Локальный протокол ###
-Базовым протоколом является _Локальный протокол_, при использовании которого удалённый репозиторий другой каталог на диске. Наиболее часто он используется, если все члены команды имеют доступ к общей файловой системе, например к NFS, или, что менее вероятно, когда все работают на одном компьютере. Последний вариант не столь хорош, поскольку все копии вашего репозитория находятся на одном компьютере, делая возможность потерять всё более вероятной.
+Базовым протоколом является _Локальный протокол_, при использовании которого удалённый репозиторий другой каталог на диске. Наиболее часто он используется, если все члены команды имеют доступ к общей файловой системе, например к NFS, или, что менее вероятно, когда все работают на одном компьютере. Последний вариант не столь хорош, поскольку все копии вашего репозитория находятся на одном компьютере, делая возможность потерять всё более вероятной.
Если у вас смонтирована общая файловая система, вы можете клонировать, отправлять и получать изменения из локального репозитория. Чтобы склонировать такой репозиторий или добавить его в качестве удалённого в существующий проект, используйте путь к репозиторию в качестве URL. Например, для клонирования локального репозитория вы можете выполнить что-то вроде этого:
@@ -62,7 +62,7 @@ Git работает немного по-другому если вы укаже
#### Достоинства ####
-SSH имеет множество достоинств. Во-первых, вы, по сути, вынуждены его использовать, когда нужен авторизованный доступ на запись к репозиторию через сеть. Во-вторых, SSH достаточно легко настроить ― SSH-демоны распространены, многие системные администраторы имеют опыт работы с ними, и во многих дистрибутивах они уже настроены или есть утилиты для управления ими. Также доступ по SSH безопасен ― данные передаются зашифрованными по авторизованным каналам. Наконец, так же как и Git-протокол и локальный протокол, SSH эффективен, делая данные перед передачей максимально компактными.
+SSH имеет множество достоинств. Во-первых, вы, по сути, вынуждены его использовать, когда нужен авторизованный доступ на запись к репозиторию через сеть. Во-вторых, SSH достаточно легко настроить — SSH-демоны распространены, многие системные администраторы имеют опыт работы с ними, и во многих дистрибутивах они уже настроены или есть утилиты для управления ими. Также доступ по SSH безопасен — данные передаются зашифрованными по авторизованным каналам. Наконец, так же как и Git-протокол и локальный протокол, SSH эффективен, делая данные перед передачей максимально компактными.
#### Недостатки ####
@@ -70,11 +70,11 @@ SSH имеет множество достоинств. Во-первых, вы,
### Git-протокол ###
-Следующий протокол ― Git-протокол. Вместе с Git'ом поставляется специальный демон, который слушает порт 9418 и предоставляет сервис, схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл `git-export-daemon-ok`, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно, любой репозиторий в Git'е может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие, обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно, зная URL вашего проекта, сможет его изменить. В общем, это редко используемая возможность.
+Следующий протокол — Git-протокол. Вместе с Git'ом поставляется специальный демон, который слушает порт 9418 и предоставляет сервис, схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл `git-export-daemon-ok`, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно, любой репозиторий в Git'е может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие, обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно, зная URL вашего проекта, сможет его изменить. В общем, это редко используемая возможность.
#### Достоинства ####
-Git-протокол самый быстрый из доступных протоколов. Если у вас проект с публичным доступом и большой трафик или у вас очень большой проект, для которого не требуется авторизация пользователей для чтения, вам стоит настроить Git-демон для вашего проекта. Он использует тот же механизм передачи данных, что и протокол SSH, но без дополнительных затрат на кодирование и аутентификацию.
+Git-протокол самый быстрый из доступных протоколов. Если у вас проект с публичным доступом и большой трафик или у вас очень большой проект, для которого не требуется авторизация пользователей для чтения, вам стоит настроить Git-демон для вашего проекта. Он использует тот же механизм передачи данных, что и протокол SSH, но без дополнительных затрат на кодирование и аутентификацию.
#### Недостатки ####
@@ -83,7 +83,7 @@ Git-протокол ― самый быстрый из доступных пр
### Протокол HTTP/S ###
-Последний доступный протокол ― HTTP. Прелесть протоколов HTTP и HTTPS в простоте их настройки. По сути, всё, что необходимо сделать ― поместить голый репозиторий внутрь каталога с HTTP документами, установить перехватчик `post-update` и всё (подробнее о перехватчиках будет рассказано в главе 7). Теперь каждый, имеющий доступ к веб-серверу, на котором был размещён репозиторий, может его склонировать. Таким образом, чтобы открыть доступ к своему репозиторию на чтение через HTTP, нужно сделать что-то наподобие этого:
+Последний доступный протокол — HTTP. Прелесть протоколов HTTP и HTTPS в простоте их настройки. По сути, всё, что необходимо сделать — поместить голый репозиторий внутрь каталога с HTTP документами, установить перехватчик `post-update` и всё (подробнее о перехватчиках будет рассказано в главе 7). Теперь каждый, имеющий доступ к веб-серверу, на котором был размещён репозиторий, может его склонировать. Таким образом, чтобы открыть доступ к своему репозиторию на чтение через HTTP, нужно сделать что-то наподобие этого:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
@@ -109,7 +109,7 @@ Git-протокол ― самый быстрый из доступных пр
#### Недостатки ####
-Обратной стороной использования протокола HTTP является его относительно низкая эффективность для клиента. Обычно клонирование или извлечение изменений из репозитория при использовании HTTP гораздо продолжительнее, а объем данных и нагрузка на сеть намного больше, чем у любого другого имеющегося сетевого протокола. Поскольку он не заботится о том, чтобы передавались только необходимые вам данные ― никакой динамической обработки на стороне сервера в этом случае не происходит ― протокол HTTP часто называют _тупым_ (dumb) протоколом. Более подробно о разнице в эффективности протокола HTTP и других протоколов рассказывается в главе 9.
+Обратной стороной использования протокола HTTP является его относительно низкая эффективность для клиента. Обычно клонирование или извлечение изменений из репозитория при использовании HTTP гораздо продолжительнее, а объем данных и нагрузка на сеть намного больше, чем у любого другого имеющегося сетевого протокола. Поскольку он не заботится о том, чтобы передавались только необходимые вам данные — никакой динамической обработки на стороне сервера в этом случае не происходит — протокол HTTP часто называют _тупым_ (dumb) протоколом. Более подробно о разнице в эффективности протокола HTTP и других протоколов рассказывается в главе 9.
## Настройка Git на сервере ##
@@ -143,15 +143,15 @@ Git-протокол ― самый быстрый из доступных пр
$ cd /opt/git/my_project.git
$ git init --bare --shared
-Видите, это просто взять Git-репозиторий, создать его "голую" версию и поместить её на сервер, к которому у вас и ваших коллег есть доступ по SSH. Теперь вы готовы работать вместе над одним проектом.
+Видите, это просто взять Git-репозиторий, создать его "голую" версию и поместить её на сервер, к которому у вас и ваших коллег есть доступ по SSH. Теперь вы готовы работать вместе над одним проектом.
-Важно отметить, что это практически всё, что вам нужно сделать, чтобы получить рабочий Git-сервер, к которому несколько человек имеют доступ просто добавьте учётные записи SSH на сервер, и положите голый репозиторий в место, к которому эти пользователи имеют доступ на чтение и запись. И всё.
+Важно отметить, что это практически всё, что вам нужно сделать, чтобы получить рабочий Git-сервер, к которому несколько человек имеют доступ просто добавьте учётные записи SSH на сервер, и положите голый репозиторий в место, к которому эти пользователи имеют доступ на чтение и запись. И всё.
-Из нескольких последующих разделов вы узнаете, как получить более сложные конфигурации. В том числе как не создавать учётные записи для каждого пользователя, как сделать публичный доступ на чтение репозитория, как установить веб-интерфейс, как использовать Gitosis, и др. Однако, помните, что для совместной работы пары человек на закрытом проекте, всё, что вам _нужно_ это SSH-сервер и "голый" репозиторий.
+Из нескольких последующих разделов вы узнаете, как получить более сложные конфигурации. В том числе как не создавать учётные записи для каждого пользователя, как сделать публичный доступ на чтение репозитория, как установить веб-интерфейс, как использовать Gitosis, и др. Однако, помните, что для совместной работы пары человек на закрытом проекте, всё, что вам _нужно_ это SSH-сервер и "голый" репозиторий.
### Малые установки ###
-Если вы небольшая фирма или вы только пробуете Git в вашей организации и у вас мало разработчиков, то всё достаточно просто. Один из наиболее сложных аспектов настройки Git-сервера управление пользователями. Если вы хотите, чтобы некоторые репозитории были доступны некоторым пользователям только на чтение, а другие и на чтение, и на запись, вам может быть не очень просто привести права доступа в порядок.
+Если вы небольшая фирма или вы только пробуете Git в вашей организации и у вас мало разработчиков, то всё достаточно просто. Один из наиболее сложных аспектов настройки Git-сервера управление пользователями. Если вы хотите, чтобы некоторые репозитории были доступны некоторым пользователям только на чтение, а другие и на чтение, и на запись, вам может быть не очень просто привести права доступа в порядок.