├── .gitattributes ├── .gitignore ├── README ├── Rakefile ├── ar ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown ├── 09-git-internals │ └── 01-chapter9.markdown ├── NOTES └── README ├── by └── 01-introduction │ └── 01-chapter1.markdown ├── couchapp ├── .couchapprc ├── Makefile ├── Readme.md ├── _id ├── shows │ └── chapter.js ├── templates │ ├── foot.html │ └── head.html └── vendor │ ├── markdown │ └── showdown.js │ └── mustache.js │ └── mustache.js ├── cs ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── de ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown ├── 09-git-internals │ └── 01-chapter9.markdown ├── NOTES ├── README └── STATUS ├── ebooks └── cover.png ├── en ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── eo └── 01-introduction │ └── 01-chapter1.markdown ├── epub ├── ProGit.css └── title.png ├── es-mx └── 01-introduction │ └── 01-chapter1.markdown ├── es-ni ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── es ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown ├── 09-git-internals │ └── 01-chapter9.markdown ├── GitPro-omegat-Benzirpi.tmx ├── GitPro-omegat.tmx ├── NOTES ├── README ├── glosario-Benzirpi.tab └── glosario.tab ├── fi ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown └── NOTES ├── figures-dia ├── fig0101.dia ├── fig0102.dia └── makeimages ├── figures-source └── progit.graffle ├── figures ├── 18333fig0101-tn.png ├── 18333fig0102-tn.png ├── 18333fig0103-tn.png ├── 18333fig0104-tn.png ├── 18333fig0105-tn.png ├── 18333fig0106-tn.png ├── 18333fig0107-tn.png ├── 18333fig0201-tn.png ├── 18333fig0202-tn.png ├── 18333fig0301-tn.png ├── 18333fig0302-tn.png ├── 18333fig0303-tn.png ├── 18333fig0304-tn.png ├── 18333fig0305-tn.png ├── 18333fig0306-tn.png ├── 18333fig0307-tn.png ├── 18333fig0308-tn.png ├── 18333fig0309-tn.png ├── 18333fig0310-tn.png ├── 18333fig0311-tn.png ├── 18333fig0312-tn.png ├── 18333fig0313-tn.png ├── 18333fig0314-tn.png ├── 18333fig0315-tn.png ├── 18333fig0316-tn.png ├── 18333fig0317-tn.png ├── 18333fig0318-tn.png ├── 18333fig0319-tn.png ├── 18333fig0320-tn.png ├── 18333fig0321-tn.png ├── 18333fig0322-tn.png ├── 18333fig0323-tn.png ├── 18333fig0324-tn.png ├── 18333fig0325-tn.png ├── 18333fig0326-tn.png ├── 18333fig0327-tn.png ├── 18333fig0328-tn.png ├── 18333fig0329-tn.png ├── 18333fig0330-tn.png ├── 18333fig0331-tn.png ├── 18333fig0332-tn.png ├── 18333fig0333-tn.png ├── 18333fig0334-tn.png ├── 18333fig0335-tn.png ├── 18333fig0336-tn.png ├── 18333fig0337-tn.png ├── 18333fig0338-tn.png ├── 18333fig0339-tn.png ├── 18333fig0401-tn.png ├── 18333fig0402-tn.png ├── 18333fig0403-tn.png ├── 18333fig0404-tn.png ├── 18333fig0405-tn.png ├── 18333fig0406-tn.png ├── 18333fig0407-tn.png ├── 18333fig0408-tn.png ├── 18333fig0409-tn.png ├── 18333fig0410-tn.png ├── 18333fig0411-tn.png ├── 18333fig0412-tn.png ├── 18333fig0413-tn.png ├── 18333fig0414-tn.png ├── 18333fig0415-tn.png ├── 18333fig0501-tn.png ├── 18333fig0502-tn.png ├── 18333fig0503-tn.png ├── 18333fig0504-tn.png ├── 18333fig0505-tn.png ├── 18333fig0506-tn.png ├── 18333fig0507-tn.png ├── 18333fig0508-tn.png ├── 18333fig0509-tn.png ├── 18333fig0510-tn.png ├── 18333fig0511-tn.png ├── 18333fig0512-tn.png ├── 18333fig0513-tn.png ├── 18333fig0514-tn.png ├── 18333fig0515-tn.png ├── 18333fig0516-tn.png ├── 18333fig0517-tn.png ├── 18333fig0518-tn.png ├── 18333fig0519-tn.png ├── 18333fig0520-tn.png ├── 18333fig0521-tn.png ├── 18333fig0522-tn.png ├── 18333fig0523-tn.png ├── 18333fig0524-tn.png ├── 18333fig0525-tn.png ├── 18333fig0526-tn.png ├── 18333fig0527-tn.png ├── 18333fig0601-tn.png ├── 18333fig0701-tn.png ├── 18333fig0702-tn.png ├── 18333fig0703-tn.png ├── 18333fig0901-tn.png ├── 18333fig0902-tn.png ├── 18333fig0903-tn.png └── 18333fig0904-tn.png ├── fr ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown ├── 09-git-internals │ └── 01-chapter9.markdown ├── NOTES.fr-fr.markdown └── glossaire-git.adoc ├── hu └── 01-introduction │ └── 01-chapter1.markdown ├── id ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown └── 03-git-branching │ └── 01-chapter3.markdown ├── it ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── ja ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown ├── 09-git-internals │ └── 01-chapter9.markdown ├── README └── translation glossaries.txt ├── ko └── 01-introduction │ └── 01-chapter1.markdown ├── latex ├── README ├── config.yml ├── makepdf └── template.tex ├── makeebooks ├── makepdfs ├── mk ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── nl ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── pl ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 02-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown └── translation-guidelines.txt ├── pt-br ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown ├── ro └── 01-introduction │ └── 01-chapter1.markdown ├── ru ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown └── figures-dia │ └── fig0101.dia ├── sr └── 01-introduction │ └── 01-chapter1.markdown ├── summary.rb ├── th ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown ├── 09-git-internals │ └── 01-chapter9.markdown └── README ├── zh-tw ├── 01-introduction │ └── 01-chapter1.markdown ├── 02-git-basics │ └── 01-chapter2.markdown ├── 03-git-branching │ └── 01-chapter3.markdown ├── 04-git-server │ └── 01-chapter4.markdown ├── 05-distributed-git │ └── 01-chapter5.markdown ├── 06-git-tools │ └── 01-chapter6.markdown ├── 07-customizing-git │ └── 01-chapter7.markdown ├── 08-git-and-other-scms │ └── 01-chapter8.markdown └── 09-git-internals │ └── 01-chapter9.markdown └── zh ├── 01-introduction └── 01-chapter1.markdown ├── 02-git-basics └── 01-chapter2.markdown ├── 03-git-branching └── 01-chapter3.markdown ├── 04-git-server └── 01-chapter4.markdown ├── 05-distributed-git └── 01-chapter5.markdown ├── 06-git-tools └── 01-chapter6.markdown ├── 07-customizing-git └── 01-chapter7.markdown ├── 08-git-and-other-scms └── 01-chapter8.markdown └── 09-git-internals └── 01-chapter9.markdown /.gitattributes: -------------------------------------------------------------------------------- 1 | *.graffle binary 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | progit.*.pdf 2 | progit.*.mobi 3 | progit.*.epub 4 | progit.*.html 5 | progit-*.epub 6 | *.swp 7 | latex/* 8 | !latex/makepdf 9 | !latex/README 10 | !latex/template.tex 11 | !latex/config.yml 12 | epub/temp 13 | *~ 14 | .#* 15 | figures/* 16 | -------------------------------------------------------------------------------- /README: -------------------------------------------------------------------------------- 1 | Pro Git Book Contents 2 | ===================== 3 | 4 | This is the source code for the Pro Git book contents. It is licensed under the 5 | Creative Commons Attribution-Non Commercial-Share Alike 3.0 license. I hope you 6 | enjoy it, I hope it helps you learn Git, and I hope you'll support Apress and me 7 | by purchasing a print copy of the book at Amazon: 8 | 9 | http://tinyurl.com/amazonprogit 10 | 11 | Making Ebooks 12 | ===================== 13 | 14 | On Fedora you can run something like this: 15 | 16 | $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug 17 | $ gem install rdiscount 18 | $ makeebooks en # will produce a mobi 19 | 20 | Errata 21 | ===================== 22 | If you see anything that is technically wrong or otherwise in need of correction, 23 | please email me at schacon at gmail dot com to inform me. 24 | 25 | 26 | Translation 27 | ===================== 28 | If you wish to translate the book, I will put the translation up on the progit.org 29 | site. Please put your translation into the appropriate subdirectory of this 30 | project (ie: 'it' for Italian and so forth) and send me (schacon) a pull request. 31 | -------------------------------------------------------------------------------- /Rakefile: -------------------------------------------------------------------------------- 1 | # encoding: UTF-8 2 | 3 | require 'rake/clean' 4 | 5 | 6 | $lang = ENV['language'] 7 | $lang ||= 'en' 8 | 9 | namespace :epub do 10 | TMP_DIR = File.join('epub', 'temp', $lang) 11 | INDEX_FILEPATH = File.join(TMP_DIR, 'progit.html') 12 | TARGET_FILEPATH = "progit-#{$lang}.epub" 13 | 14 | SOURCE_FILES = FileList.new(File.join($lang, '**', '*.markdown')).sort 15 | CONVERTED_MK_FILES = SOURCE_FILES.pathmap(File.join(TMP_DIR, '%f')) 16 | HTML_FILES = CONVERTED_MK_FILES.ext('html') 17 | 18 | desc "generate EPUB ebook (add language=xx to build lang xx)" 19 | task :generate => :check 20 | task :generate => TARGET_FILEPATH 21 | 22 | desc "check whether all the required tools are installed" 23 | task :check do 24 | begin 25 | require 'maruku' 26 | found_maruku = true 27 | rescue LoadError 28 | found_maruku = false 29 | end 30 | 31 | $ebook_convert_cmd = ENV['ebook_convert_path'].to_s 32 | if $ebook_convert_cmd.empty? 33 | $ebook_convert_cmd = `which ebook-convert`.chomp 34 | end 35 | if $ebook_convert_cmd.empty? 36 | mac_osx_path = '/Applications/calibre.app/Contents/MacOS/ebook-convert' 37 | $ebook_convert_cmd = mac_osx_path 38 | end 39 | found_calibre = File.executable?($ebook_convert_cmd) 40 | 41 | if !found_maruku 42 | puts 'EPUB generation requires the Maruku gem.' 43 | puts ' On Ubuntu call "sudo apt-get install libmaruku-ruby".' 44 | end 45 | if !found_calibre 46 | puts 'EPUB generation requires Calibre.' 47 | puts ' On Ubuntu call "sudo apt-get install calibre".' 48 | end 49 | 50 | if !found_calibre || !found_maruku then exit 1 end 51 | end 52 | 53 | directory TMP_DIR 54 | 55 | rule '.html' => '.mk' do |t| 56 | require 'maruku' 57 | 58 | mk_filename = t.source 59 | html_filename = t.name 60 | puts "Converting #{mk_filename} -> #{html_filename}" 61 | 62 | mk_file = File.open(mk_filename, 'r') do |mk| 63 | html_file = File.open(html_filename, 'w') do |html| 64 | code = Maruku.new(mk.read.encode("UTF-8")).to_html 65 | code.gsub!(/^( src_for_converted do |t| 78 | src_filename = t.source 79 | dest_filename = t.name 80 | puts "Processing #{src_filename} -> #{dest_filename}" 81 | 82 | figures_dir = "../../../figures" 83 | 84 | dest_file = File.open(dest_filename, 'w') 85 | src_file = File.open(src_filename, 'r') 86 | until src_file.eof? 87 | line = src_file.readline 88 | 89 | matches = line.match /^\s*Insert\s(.*)/ 90 | if matches 91 | image_path = matches[1] 92 | real_image_path = image_path.pathmap("#{figures_dir}/%X-tn%x") 93 | 94 | next_line = src_file.readline.chomp 95 | 96 | line = "![#{next_line}](#{real_image_path} \"#{next_line}\")\n" 97 | end 98 | 99 | dest_file << line 100 | end 101 | src_file.close 102 | dest_file.close 103 | end 104 | 105 | file INDEX_FILEPATH => TMP_DIR 106 | file INDEX_FILEPATH => HTML_FILES do 107 | index_file = File.open(INDEX_FILEPATH, 'w') do |file| 108 | file << '' 109 | file << "\n" 110 | file << '' 112 | file << "\n" 113 | file << "" 114 | file << '' 115 | file << 'Pro Git - professional version control' 116 | file << '' 117 | file << '' 118 | file << "\n" 119 | 120 | HTML_FILES.each do |chapter_file| 121 | file << File.open(chapter_file).read 122 | file << "\n" 123 | end 124 | 125 | file << '' 126 | file << "\n" 127 | end 128 | end 129 | 130 | file TARGET_FILEPATH => INDEX_FILEPATH do 131 | opts = [ 132 | '--language', $lang, 133 | '--authors', 'Scott Chacon', 134 | '--comments', 'Licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license', 135 | 136 | '--cover', 'epub/title.png', 137 | '--extra-css', 'epub/ProGit.css', 138 | 139 | '--chapter', '//h:h1', 140 | '--level1-toc', '//h:h1', 141 | '--level2-toc', '//h:h2', 142 | '--level3-toc', '//h:h3', 143 | ] 144 | 145 | sh $ebook_convert_cmd, INDEX_FILEPATH, TARGET_FILEPATH, *opts 146 | end 147 | 148 | CLEAN.push(*CONVERTED_MK_FILES) 149 | CLEAN.push(*HTML_FILES) 150 | CLEAN << INDEX_FILEPATH 151 | CLEAN << TMP_DIR 152 | CLOBBER << TARGET_FILEPATH 153 | end 154 | 155 | namespace :pdf do 156 | desc "generate a pdf" 157 | task :generate do 158 | system("ruby makepdfs") 159 | end 160 | end 161 | -------------------------------------------------------------------------------- /ar/01-introduction/01-chapter1.markdown: -------------------------------------------------------------------------------- 1 | # الإستعداد للبدء! # 2 | 3 | يحتوي هذا الفصل على معلومات تعدك للبدء بإستخدام Git. سنبدأ بشرح بعض المعلومات الأساسية عن نظم إدارة الإصدارات (Version Control System)، ثم سننتقل إلى كيفية تنصيب وتشغيل Git على نظامك ومن ثم كيف يمكنك استخدامها في عملك. في نهاية الفصل ستكون قد تعرفت على أهمية وجود Git، لماذا عليك إستخدامها وكيف تستعد لذلك. 4 | 5 | ## إدارة الإصدارات (Version Control) ## 6 | 7 | ما هو نظام إدارة الإصدارات، ولماذا عليك أن تهتم به؟ تمكنك هذه الأنظمة من تسحيل التغيرات التي تحدث على ملف أو مجموعة ملفات خلال الزمن بحيث يمكنك الرجوع الى مرحلة معينة (إصدار) لاحقاً. فعلى سبيل المثال، ستستخدم في هذا الكتاب الكود المصدري للملفات في حين أنه تتم إدارتها من قبل نظام إدارة الإصدارات، ولكن في الحقيقة يمكنك استخدام هذه الأنظمة مع أي نوع من الملفات على حاسوبك. 8 | 9 | إذا كنت تعمل كمصمم غرافيك أو ويب وتريد طريقة لمتابعة جميع الإصدارت والتعديلات التي تجريها على صورة أو قالب ما (الأمر الذي سيعجبك بالتأكيد)، فإن نظام إدارة الإصدارات (VCS) هو الحل الأمثل. حيث يمكنك من إرجاع الملفات الى حالة كانت عليها سابقاً، أو ارجاع المشروع بأكمله لحالة سابقة، يمكنك أيضاً مقارنة التغيرات الحاصلة مع مرور الزمن، أو معرفة من قام بتعديل معين أدى الى خطأ ما، من قام بتقديم إقتراح ومتى قام بذلك، والمزيد. إستخدامك لنظام إدارة الإصدارات يعني أيضاً أنه اذا قمت بخطأ ما في مرحلة من المراحل أو خسرت ملفات المشروع لسبب ما، يمكنك استرجاعها الى حالها بسهولة. كل هذه الميزات مقابل تعب خفيف منك. 10 | 11 | ### نظم إدارة الإصدارات المحلية ### 12 | 13 | تقوم الطريقة التي يقوم بها معظم المستخدمين لإدارة إصداراة مشاريعهم على "نسخ الملفات" الى مكان آخر. يقوم المعظم بهذه الطريقة لأنها تبدوا وكأنها الحل الأسهل، ولكنها تجلب المشاكل والأخطاء بشكل لا يحتمل أيضاً. من السهل جداً أن تنسى بأي مجلد وضعت نسخة معينة أو أن تقوم بالتغيير أو الحذف عن طريق الخطا لملف ما. 14 | 15 | لعلاج هذه المشكلة، قام المبرمجون بتطوير أنظمة إدارة إصدارات المحلية، حيث تستخدم قاعدة بيانات بسيطة تحفظ فيها التغيرات على الملفات في نظام إصدارات معين (إنظر الشكل 1-1). 16 | 17 | 18 | Insert 18333fig0101.png 19 | الشكل 1-1. مخطط أنظمة إدارة الإصدارات المحلية. 20 | 21 | أحد أشهر أنظمة إدارة الإصدارات هو نظام يدعى rcs، والذي مازال يتم توزيعه مع العديد من الحواسيب في يومنا هذا. حتى أن أنظمة Mac OS X الشهيرة تحوي نظام rcs مضمنة في حزمة برامج التطوير Developer Tools. يقوم عمل هذه الأداة ببساطة على حفظ مجموعات من الإصلاحات (Patch sets) (أي فروقات بين الملفات بمعنى آخر) من تغيير الى آخر بطريقة خاصة; يمكنها بعد ذلك اعادة تشكيل أي ملف بالطريقة التي كان عليها في أي مرحلة خلال حياة الملف عن طريق اضافة جميع هذه التغيرات. 22 | 23 | ### أنظمة إدارة الإصدارات المركزية ### 24 | 25 | المشكلة التالية التي ظهرت هي الرغبة في التعاون والتشارك بين المطورين الذين يعملون على أنظمة أخرى. لحل هذه المشكلة تم إنشاء أنظمة إدارة الإصدارات المركزية Centralized Version Control Systems. تقوم هذه الأنظمة، مثل CVS, Subversion و Perforce على مخدم Server واحد يحتوي على جميع الملفات، وعدد من المستخدمين Clients تقوم بطلب هذه الملفات من مكان وجودها المركزي. للعديد من السنوات، كانت هذه الأنظمة هي المسيطرة على عالم إدارة الإصدارات (انظر الشكل 1-2). 26 | 27 | Insert 18333fig0102.png 28 | الشكل 1-2. مخطط أنظمة إدارة الإصدارات المركزية. 29 | 30 | تقدم هذه الطرقة العديد من الأفضليات على أنظمة ادارة الإصدارات المحلية. فعلى سبيل المثال، جميع المشاركين في المشروع يعرف مالذي يقوم به المشارك الآخر الى حد معين. مدراء المشروع يستطيعون التحكم بمن يستطيع فعل ماذا في النظام العام; وبالطبع فإنه من الأسهل التعامل مع أنظمة إدارة الإصدارات المركزية على التعامل مع الأنظمة المحلية وقاعدات بياناتها من قبل كل مستخدم. 31 | 32 | ولكن، ومن جهة ثانية، فإن لهذه الطريقة جانباً سيئاً أيضاً. أهم هذه النقاط السيئة هي أنه هذه الأنظمة المركزية تقوم على مركز واحد للكود، أي إنه اذا حصل وتوقف المخدم لساعة، فلن يتمكن أحد من خفظ التغييرات أو القيام بأي تعديل على أي شيء يعمل عليه. إذا حصل وأن تعطل القرص الأساسي والذي يحوي على قاعدة البيانات المركزية، ولم تعمل النسخ الإحتياطية المخبأة، فإنك ستخسر كل شي عن تاريخ عملك في المشروع. تعاني أنظمة إدارة الإصدارات المحلية من هذه المشكلة أيضاً، وهي أنه عندما تكون جميع ملفات المشروع في مكان واحد فإنك على خطر من خساراة كل شيء! 33 | 34 | ### أنظمة إدارة الإصدارات الموزعة ### 35 | 36 | وهنا تأتي أنظمة إدارة الإصدارات الموزعة لحل المشكلة. في هذه الأنظمة (مثل Git, Mercurial, Bazaar أو Darcs) يحصل المستخدمون ليس فقط على آخر نسخة من الملفات الموجود على المخدم، بل على كامل تاريخ النظام. في هذه الحال، إن تعطل النظام، فإنه يمكن الحصول على نسخة من المشروع من أي مستخدم الى المخدم مرة أخرى. أي أن كل عملية طلب للكود هي في الحقيقة عملية حفظ كاملة وشاملة لتاريخ المشروع (إنظ الشكل 1-3). 37 | 38 | 39 | Insert 18333fig0103.png 40 | الشكل 1-3. مخطط أنظمة إدارة الإصدارات الموزعة. 41 | 42 | وفوق هذا فإن معظم هذه الأنظمة يتعامل بشكل جيد جداً مع أكثر من نسخة خارجية للمشروع، أي يمكنك التعاون مع أكثر من مجموعة مختلفة من الأشخاص في طرقة مختلفة وفي وقت واحد وعلى مشروع واحد. يمكنك هذا من تطوير أكثر من طريقة عمل واحدة مناسبة لك، الأمر الذي لم يكن متاحاً مع أنظمة إدارة الإصدارات المركزية. 43 | 44 | ## لمخة تاريخية عن Git ## 45 | 46 | كما تبدأ العديد من الأشياء الجميلة في الحياة، بدأت Git كنوع من التدمير المبدع المثير للجدل. الـ Linux Kernel المعروف هو برنامج مفتوح المصدر ذو إطار واسع نوعاً ما. طوال حياة هذا المشروع (من 1991-2002)، كان يتم تناقل التعديلات على شكل ملفات إصلاح و ملفات مؤرشفة (مضغوطة). في 2002، في 2002 بدأ المشروع باستخدام نظام إدارة إصارات موزعة DVCS يدعى BitKeepter. 47 | 48 | في 2005، بدأت العلاقة بالإنهيار بين المجتمع المطور للـ Linux Kernel والمجتمع التجاري المطور لـ BitKeeper، وتم العدول عن توفير البنامج بشكل مجاني. أثار هذا التغيير الرغبة في المجتمع المطور لـ Linux (وبالتحديد لينوس تورفالدوس، منشيء Linux) الى تطوير نظامهم الخاص بناء على الدروس التي تعلموها عند استخدامهم لـ BitKee[per. وتم وضع أهداف لكي يحققها النظام الجديد مشمولة بـ: 49 | 50 | * السرعة 51 | * التصميم البسيط 52 | * الدعم القوي للبرمجة الغير خطية (الكثير من أشجار التطوير الفرعي) 53 | * التوزيع بشكل كامل 54 | * القدرة على تحمل مشروعات ضمة مثل الـ Linux Kernel بشكل فعال (السرعة وحجم المعلومات) 55 | 56 | منذ ولادة Git في 2005، تطورت لكي تصبح ناضجة مع المحافظة على السهولة والمبادئ الأساسية التي وضعت عليها. حيث أنها سريعة بشكل لايصدق، و فعالة مع المشاريع الكبيرة، وتحوي على نظام تشجير ممتاز لدعم التطوير الغير خطي (انظر الفصل 3). 57 | 58 | ## أوليات Git ## 59 | 60 | لنتحدث الآن عن Git بشكل سريع. هذا القسم هام جداً لك، لأنك إذا عرفت ماهي Git وماهيا أوليات عملها، سيكون من السهل عليك استخدام Git بشكل أسهل وأفضل. وخلال تعلمك لـ Git حاول أن تفرغ ذهنك من المعلومات السابقة عن أنظمة إدارة الإصدارات الأخرى، مثل Subversion أو Perforce; سيجنبك هذا من الخلط بين المعلومات عند استخدام هذه الأداة. تقوم Git بالتعامل وتخزين المعلومات بشكل مختلف تماماً عن الأنظمة الأخرى، وبالرغم من أن واجهة الإستخدام بسيطة نسبياً; سيكون فهمك لهذه الإختلافات سيبعد عنك الحيرة عند الإستخدام. 61 | 62 | ### لفطات، وليست تغيرات ### 63 | 64 | الفرق الرئيسي بين Git وأي نظام إدارة إصدارات آخر (Subversion وأصدقاءه) هو الطريقة التي تتعامل بها Git مع المعلومات. تقوم معظم هذه الأنظمة بتخزين المعلومات كقائمة من التغيرات القائمة على الملفات. هذه الأنظمة (مثل CVS، Subversion، Perforce، Bazaar وغيرها) تتعامل مع المعلومات التي تحفظها كمجموعة ملفات والتغيرات القائمة عليها مع مرور الوقت، كما هو موضح في الشكل 1-4. 65 | 66 | Insert 18333fig0104.png 67 | الشكل 1-4. الأنظمة الاخرى تقوم بحفظ معلومات التغيرات الحاصلة على كل ملف وكنها الإصدار الأول. 68 | 69 | الأمر مختلف مع Git. حيث تعامل Git المعلومات المخزنة على أنها "لقطات" من نظام ملفات مصغر. ففي كل مرة تقوم بـ Commit أو تحفظ حالة المشروع، تقوم Git بأخذ صورة عن جميع الملفات في تلك اللحظة وتخزن رابطاً الى تلك اللقطة. ومن أجل السرعة، إذا لم يتغير الملف، لا تقوم Git بحفظة، بل تحفظ رابطاً عن الملف الأسبق منه المطابق. تتعامل Git مع المعلومات كما هو موضح في الشكل 1-5. 70 | 71 | Insert 18333fig0105.png 72 | الشكل 1-5. تحفظ Git المعلومات على أنها "لفطات". 73 | 74 | وبالطبع، هذا الإختلاف بين Git وبين جميع أنظمة إدارة الإصدارات الأخرى تقريباً. يجعل هذا Git أشبه بنظام ملفات مصغر مزود بأدوات خارقة مبنية عليه، عوضاً عن نظام إدارة إصدارات عادي. سنقوم بشرح الفوائد التي تحصل عليها عندما تتعامل مع المعلومات بهذه الطريقة في الفصل الثالث "التشعيب في Git". 75 | 76 | ### جميع العمليات هي عمليات داخلية تقريباً ### 77 | 78 | أغلب العمليات في Git لا تحتاج سوى ملفات ومصادر داخلية لتعمل - أي بشكل عام، لا توجد معلومات تحتاجها من حاسوب آخر من الشبكة. إذا كنت قد استخدمت أحد أنظمة إداراة الإصدارات الأخرى والتي تعتمد عملياتها بشكل كبير على الشبكة فإن هذا سيجعلك تعتقد أن آلهة السرعة قد باركت Git وأعطتها هذه السرعة الجبارة. ستجد أنك تملك كامل تاريخ مشروعك موجود أمامك مباشرة، وأغلب العمليات أقرب ما تكون الى الآنية. 79 | 80 | فعلى سبيل المثال، لكي تستعرض تاريخ مشروعك، لن تحتاج Git الى الذهاب الى مخدم معين للحصول علىه وعرضه، بل تقوم بقراءته مباشرة من حاسوبك. اي انك ستحصل على تاريخ مشروعك بشكل مباشر. اذا أردت استعراض التغيرات الحاصلة بين الإصدار الحالي لملف ما واصدار الشهر السابق، تستطيع Git النظر الى الملف من الشهر السابق وحساب الفروقات بينهما مباشرة، عوضاً عن طلب هذه المعلومات من مخدم خارجي. 81 | 82 | هذا يعني أيضاً أن الأمور التي لا تستطيع فعلها عندما تكون مفصولاً عن الإنترنت أو عن الشبكة الداخلية قليلة جداً. إذا كنت في طائرة أو في القطار ولم تستطيع الإرتباط بالشبكة بشكل صحيح، يمكنك إكمال عملك بشكل طبيعي. في الأنظمة الأخرى يكون هذا الأمر مستحيلاً! أو من الممكن لك أن تعدل الملفات ولكن دون عمليات Commit لتغييراتك. في نظام Perforce على سبيل المثال، لا يمكنك فعل الكثير حينما تكون مفصولاً عن المخدم الأساسي; وفي Subversion أو CVS، يمكنك التعديل على الملفات لكن بدون عمليات Commit لتعديلاتك، قد تعتقد بأن هذا ليس بالأمر الكبير، ولكن ستتفاجئ بحجم الفرق الذي يصنعه. 83 | 84 | ### Git تحمل المصداقية ### 85 | 86 | كل شيء في Git سيتم وضع Check-sum عليه قبل تخزينة حيث ستتم الإشارة اليه لاحقاً بهذه الـ checksum. هذا يعني أنه من المستحيل أن يتم تغيير أي ملف أو مجلد دون أن يتم اعلام Git بهذا التغيير. تم بناء هذه الخاصية بشكل أساسي في فلسفة وطريقة عمل Git. من المستحيل أن تخسر معلوماتك بشكل فجائي أو أن ينعطب معلف ما دون أن تعرف Git بذلك. 87 | 88 | تدعى الآلية التي تستخدمها Git لعملية الـ checksum هذه باسم SHA-1 hash. وهي عبارة عن قيمة نصية من 40 محرف ستاعشري (0-9 و a-f) ويتم حسابها بناء على محتوى الملف أو المجلد الذي تتبعه Git. يبدو الـ hash من نوع SHA-1 كما يلي: 89 | 90 | 24b9da6552252987aa493b52f8696cd6d3b00373 91 | 92 | سترى أن هذه القيم ستكون موجودة في كل مكان في Git ذلك لأنها تستخدمها بشكل كثيف. في الحقيقة، تستخدم Git هذه القيم للدلالة على الملفات في قاعدة بياناتها. 93 | 94 | ### Git تضيف المعلومات فقط! ### 95 | 96 | عندما تقوم بعملياتك في Git، ستقوم Git في أغلب الأحيان بإضافة معلومات فقط الى قاعدة البيانات. ومن الصعب جداً القيام بعملية بحيث لا يمكنك العودة الى الوراء فيها أو محيها من قاعدة البيانات بشكل نهائي. ولكن، وكما هو الأمر في أغلب نظم إدارة الإصدارات، من الممكن أن تخسر المعلومات قبل القيام بعملية Commit للتغيرات الحاصلة; ولكن بعد عملية الـ commit في Git، من الصعب جداً خسارة المعلومات، وخاصة اذا كنت تقوم بعملية push للتعديلات من قاعدة بياناتك الى repository اخرى بشكل منظم. 97 | 98 | سيضيف هذا الكثير من المتعة لإستخدامك لـ Git، لأننا نعرف أنه بإمكاننا القيام بالتجارب دون خطر تعريض المعلومات للخطر أو الضياع. للحصول على معلومات معمقة أكثر عن كيفية حفظ Git للمعلومات وكيفية استرجاعها انظر فقرة "Under the Cover" في الفصل التاسع. 99 | 100 | ### الحالات الثلاثة ### 101 | 102 | والآن عليك الإنتباه قليلاً. الأمر الأساسي الذي عليك أن تتذكره في Git اذا أردت أن تكمك تعلمك بسلاسة هو أنه في Git توجد ثلاث حالات أساسية يمكن للملفاتك أن تكون عليها: commited، معدلة أو مهيئة للعملية commit (أو staged). نعني بـ commitedf بأن المعلومات تم تخزينها بآمان في قاعدة بياناتك الخاصة. "معدل" تعني أنك قمت ببعض التعديلات على الملف ولكنك لم تقبل بعملية Commit عليه بعد. أما "مهيأ (Staged)" فتعني بأنك حددت ملفاً قمت بتعديله بإصداره الحالية ليتم حفظ في عملية الـ commit التي ستقوم بها. 103 | 104 | يقودنا هذا الى الحديث عن الأقسام الثلاثة الرئيسية في أي مشروع Git: المجلد الخاص بـ Git، مجلد العمل و مكان التهييئ (staging area). 105 | 106 | Insert 18333fig0106.png 107 | الشكل 1-6. المجلد الخاص بـ Git، مجلد العمل و مكان التهييئ (staging area). 108 | 109 | المجلد الخاص بـ Git هو المكان الذي تحفظ فيه Git المعلومات الخاصة بها عن مشروعك. هذا هو المكان الأكثر أهمية في Git، وهو الذي يتم نسخه عندما تنسخ الـ repository من حاسوب آخر. 110 | 111 | مجلد العمل هو النسخة الحالية المسحوبة من مشروعك. الملفات التي سيتم سحبها من قاعدة بيانات Git للمشروع وتجهيزها لك لتقوم بتعديلها. 112 | 113 | مكان التهييئ (staging area)، عادة ما تكون موجودة في مجلد Git لمشروعك، وتحتوي على المعلومات التي سيتم عملية commit عليها. قد يشار الى هذا المكان أيضاً باسم الفهرس (index). 114 | 115 | خطوات العمل الإعتيادية في Git غالباً ما تكون كالتالي: 116 | 117 | 1. تقوم بالتعديلات على الملفات في مجلد العمل. 118 | 2. تقوم بوضع هذه الملفات في مكان التهييئ (staging area)، حيث تقوم بإضافة اللقطات الى الـ staging area. 119 | 3. تقوم بعملية Commit، يتم أخذ الملفات المهيئة من مكان التهيئة Staging Area وتقوم بتخزين هذه الللقطة بشكل نهائي في مجلد عمل Git. 120 | 121 | إذا كان هناك إصدار معين لملف، فسيكون Commited. إذا كان معدل ومضاف إلى مكان التهييئ staging area فهو مهيئ staged. 122 | 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. 123 | 124 | ## تصيب Git ## 125 | 126 | والآن لنبدأ باستخدام Git! ولكن أولاً علينا تنصيبها على نظامنا. يمكنك الحصول على Git بأكثر من طريقة. الطريقتين الأكثر شهرة هي إما أن تنصبها يدوياً من الكود المصدري أو أن تحصل على تنصيب مهيئ لنظامك مباشرة. 127 | 128 | 129 | ### التنصيب من الكود المصدري ### 130 | 131 | بالطبع، من المفضل أن تقوم بتنصيب Git من الكود المصدري (أي أن تقوم ببناء Git يدوياً، إن استطعت) وذلك لأنك ستحصل دائماً على آخر نسخة منها. كل اصدار جديد من Git غالباً ما يحوي على تحسينات في واجهة الإستخدام. بالإضافة إلى أنك ستحصل على اصدار قديم اذا كنت تستخدم احدى توزيعات لينكس المختلفة. ولذلك، إذا لم تكن على توزيعة حديثاً جداً من المفضل أن تقوم بتنصيب مباشرة من الكود المصدري لـ Git. 132 | 133 | لتنصيب Git، عليك أن تتحق من أن نظامك يحوي على المكتبات التالية، والتي تعتمد عليها Git، وهي: curl, zlip, openssl, expat و libiconv. على سبيل المثال، اذا كنت على نظام يحوي على أداة yum (مثل فيدورا Fedora) أو apt-get (مثل ديبيان Debian)، يمكنك تشغيل أحد الأوامر التالية للتأكد من تواجد هذه المكتبات: 134 | 135 | $ yum install curl-devel expat-devel gettext-devel \ 136 | openssl-devel zlib-devel 137 | 138 | $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ 139 | libz-dev 140 | 141 | بعد تأكدك من المكتبات المطلوبة، يمكنك الحصول على آخر نسخة من الكود المصدري لـ Git من الموقع: 142 | 143 | http://git-scm.com/download 144 | 145 | ثم، يمكنك البناء والتنصيب: 146 | 147 | $ tar -zxf git-1.6.0.5.tar.gz 148 | $ cd git-1.6.0.5 149 | $ make prefix=/usr/local all 150 | $ sudo make prefix=/usr/local install 151 | 152 | بعد ذلك، ستتمكن من الحصول على تحديثات على الكود المصدري لـ Git من خلال Git نفسها :) 153 | 154 | $ git clone git://git.kernel.org/pub/scm/git/git.git 155 | 156 | ### التنصيب على لينكس ### 157 | 158 | إذا أردت تنصيب Git على نظام لينكس دون بناءه يدوياً، يمكنك ذلك من خلال أداة النصيب الخاصة بنظامك والتي تأتي مع نظامك. على سبيل المثال اذا كنت تستخدم نظام فيدورا Fedora، يمكنك استخدام yum: 159 | 160 | $ yum install git-core 161 | 162 | أو اذا كنت على نظام مبنى على ديبيان Debian مثل أوبونتو Ubuntu، يمكنك استخدام apt-get كالتالي: 163 | 164 | $ apt-get install git-core 165 | 166 | ### التنصيب على نظام الماك أو اس ### 167 | 168 | 169 | هناك طريقتين للتنصيب على ماك أو اس، الأسهل هي استخدام الواجهة الرسومية للتنصيب، والتي يمكنك تحميلها من صفحة المشروع على غوغل كود (انظر الشكل 1-7): 170 | 171 | http://code.google.com/p/git-osx-installer 172 | 173 | Insert 18333fig0107.png 174 | الشكل 1-7. تنصيب Git على ماك أو اس. 175 | 176 | والطريقة الأكثر شهرة للحصول على Git هي من خلال MacPorts، ("http://macports.org"). يمكنك تشغيل الأمر التالي اذا كنت قد نصبت MacPorts من قبل: 177 | 178 | $ sudo port install git-core +svn +doc +bash_completion +gitweb 179 | 180 | يمكنك عدم تنصيب أي من الأمور الإضافية مع Git، ولكنك ستحتاج الى +svn اذا كنت ستستخدم Git على repository تعتمد على نظام Subversion (انظر الفصل 8). 181 | 182 | 183 | ### التنصيب على ويندوز ### 184 | 185 | يمكنك تنصيب Git على نظام ويندوز بسهولة. أحد أسهل الطرق هو استخدام مشروع msysGit. يمكنك تنصيب البرنامج من صفحة المشروع على غوغل كود: 186 | 187 | http://code.google.com/p/msysgit 188 | 189 | بعد التنصيب سيكون لدين نسختين من الأداة للـ command-line في ويندوز (بالإضافة الى أداة SSH والتي ستستفيد منها لاحقاً) والأداة بالواجهة الرسومية الإعتيادية. 190 | 191 | ## إعداد Git لأول مرة ## 192 | 193 | والآن وبعد أن حصلت على Git على نظامك، سيتوجب عليك تخصيص بعض الخيارات لتناسب بيئتك. سيكون عليك القيام بهذه التعديلات مرة واحدة فقط; حتى بعد قيامك بتحديث نسختك من Git. ولكن بالطبع يمكنك تغيير هذه الإعدادات في أي وقت تريد. 194 | 195 | تأتي Git مرفقة بأداة تدعى git config والتي تمكنك تعديل الخيارات (المتغيرات) التي تتحكم بطريقة عمل Git. يتم حفظ هذه المتغيرات في أحد ثلاث أمكنة مختلفة: 196 | 197 | * في ملف `/etc/gitconfig`: يحتوي على قيم لجميع المستخديم على نظامك لجميع الـ repositories أيضاً. اذا قمت بوضع إضافة ` --system` عند تشغيل الأمر `git config`، سيتم تعديل الخيارات على هذا الملف بالتحديد. 198 | 199 | * في ملف `~/.gitconfig`: وهو مخصص للمستخدم الخاص بك فقط. سيتم تغيير الإعدادات في هذا الملف بالتحديد عن طريق إضافة `--global` الى أمر git config. 200 | 201 | * ملف الخيارات الموجود في مجلد عمل Git (الموجود في `.git/config`) في أي repository تعمل عليها، حيث تكون هذه الإعدادات مخصصة لهذه الـ repository فقط. عليك أن تعلم أيضاً بأن الإعدادات الموجودة في أي ملف سيتم تفضيلها (أي استخدامها) على المعلومات الموجودة في الملف الأعم، أي الإعدادات الموجودة في ملف الإعدادات `.git/config` ستتفوق على تلك الموجودة في `/etc/gitconfig`. 202 | 203 | على نظام ويندوز، ستقوم Git بتفحص `.gitconfig` في مجلد الـ `$HOME` (عادة تكون `C:\Documents and Settings\$USER`). ستقوم Git أيضاً بتفقد ملف /etc/gitconfig، والذي يكون مبنياً على مكان وجود MSys، والذي تحدده أنت عندما تقوم بتنصيب Git على نظامك. 204 | 205 | ### شخصيتك ### 206 | 207 | أول شيء عليك فعله بعد تنصيبك لـ Git هو اعداد اسمك وبريدك الالكتروني. أهمية هذا الأمر تكمن في أن كل عملية Commit في Git ستستخدم هذه المعلومات وسيتم لصقها بشكل غير قابل للتغيير في كل عملياتك: 208 | 209 | $ git config --global user.name "John Doe" 210 | $ git config --global user.email johndoe@example.com 211 | 212 | وطبعاً، اذا أردت أن تتحدد هذه المعلومات على كامل النظام، عليك اضافة '--global' الى الأمر. واذا أردت تجاوز هذا الأمر وتحديد معلومات مختلفة لمشروع معين، عليك تشغيل هذا الأمر بدون '--global' داخل مشروعك. 213 | 214 | ### محرر النصوص ### 215 | 216 | والآن وبعد اعداد شخصيتك، يمكنك تعيين محرر النصوص الإفتراضي والذي ستستخدمه Git عندما تحتاج منك الى ادخال رسالة ما. افتراضياً، ستستخدم Git المحرر الإفتراضي المحدد للنظام، والذي يكون عادة Vi أو Vim. إذا أردت استخدام محرر آخر، مثل Emacs، يمكن كتابة مايلي: 217 | ء 218 | $ git config --global core.editor emacs 219 | 220 | ### أداة عرض الإختلافات Diff Tool ### 221 | 222 | أمر آخر قد تهتم بتعديله عن الخيار الإفتراضي هو أداة عرض الإختلافات Diff tool والتي ستستخدمها لحل التعارضات بين الإصدارات عن الدمج. فعلى سبيل المثال، لإستخدام أداة vimdiff: 223 | 224 | $ git config --global merge.tool vimdiff 225 | 226 | تقبل Git كلا من: kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff كأدوات فعالة، يمكنك إضافة خيارات أخرى خاصة أيضاً، انظر الفصل السابع لمعلومات اخرى عن كيفية القيام بهذا. 227 | 228 | ### تغيير الإعدادات ### 229 | 230 | اذا أردت القاء نظرة على إعداداتك، يمكنك استخدام أمر 'git config --list' لعرض قائمة بكافة الخيارات التي أعددتها في Git: 231 | 232 | $ git config --list 233 | user.name=Scott Chacon 234 | user.email=schacon@gmail.com 235 | color.status=auto 236 | color.branch=auto 237 | color.interactive=auto 238 | color.diff=auto 239 | ... 240 | 241 | من الممكن أن ترى هذه المفاتيح أكثر من مرة، ذلك لأن Git تقوم بقراءة هذه المفاتيح من الملفات المختلفة (`/etc/gitconfig` و `~/.gitconfig`, على سبيل المثال). في هذه الحاله، تقوم Git باستخدام آخر قيمة موجودة لكل مفتاح مختلف. 242 | 243 | يمكنك أيضاً تفحص القيمة التي "تتعامل" معها Git لأي مفتاح مختلف عن طريق الأمر `git config {key}`: 244 | 245 | $ git config user.name 246 | Scott Chacon 247 | 248 | ## الحصول على المساعدة ## 249 | 250 | هناك أكثر من طريقة للحصول على المساعدة أثناء استخدامك لـ Git، يمكنك كتابة أحد الأوامر التالية: 251 | 252 | $ git help 253 | $ git --help 254 | $ man git- 255 | على سبيل المثال، يمكنك الحصول على المساعدة لاستخدام أمر config عن طريق الأمر التالي: 256 | 257 | $ git help config 258 | 259 | تكمن روعة هذه الأوامر بأنه يمكنك الوصول اليها من أي مكان، حتى ولو لم تكن موصولاً بالشبكة. 260 | إذا لم تكن صفحات المساعدة السابقة أو هذا الكتاب كافية بالنسبة اليك يمكنك الذهاب الى قناة #git أو #github على شبكة IRC Freenode (irc.freenode.net). عادة ما تكون هذه القنوات مليئة بالعديد من الخبراء بكيفية عمل Git ومستعدين للمساعدة. 261 | 262 | ## الملخص ## 263 | 264 | لقد حصلت حتى الآن على معلومات أولية عن نظام Git وماهي اختلفاته عن أنظمة ادارة الإصدارات المركزية الآخرى. يجب أن تكون قد حصلت على نسخة من Git تعمل على نظامك. والآن حان الوقت لتعلم بعض مبادئ استخدام Git. 265 | -------------------------------------------------------------------------------- /ar/NOTES: -------------------------------------------------------------------------------- 1 | ملاحظات حول الترجمة 2 | ======================= 3 | 4 | فيما يلي قائمة بالمصطلحات الإنكليزية ومحاولتي لتعريبها، يمكنك المشاركة في تعديل هذه المصطلحات وإقتراح الأفضل إن أردت. 5 | 6 | * نظام إدارة الإصدارات = Version Control System. 7 | * نظم إدارة الإصدارات المحلية = Local Version Control Systems. 8 | * نظم إدارة الإصدارات المركزية = Centralized Version Control Systens. 9 | 10 | 11 | ملاحظة: ستجد الكلمة الإنكليزية الأصلية بعد ترجمتي المقترحة لها في سياق الكتاب أول مرة تظهر فيها الكلمة في كل فصل فقط (أو أكثر حسب الحاجة). 12 | 13 | يحتاج الى ترجمة 14 | ======================= 15 | 16 | فيما يلي قائمة بالمصطلحات التي لم استطع العثور على ترجمة صحيحة لها، إذا كان لديك أي إقتراح أرجو التغيير أو المراسة beshrkayali at gmail dot com. 17 | 18 | * ش 19 | -------------------------------------------------------------------------------- /ar/README: -------------------------------------------------------------------------------- 1 | محتويات كتاب احترف Git 2 | ======================= 3 | هذا هو الكود المصدري لكتاب احترف Git. هذا الكتاب مرخص تحت Creative Commons Attribution-Non Commercial-Share Alike 3.0. أتمنى أن تجد فائدة في هذا الكتاب. يمكنك الحصول على نسخة مطبوعة من الكتاب من Apress (لدعم الكاتب) من متجر أمازون: 4 | 5 | http://tinyurl.com/amazonprogit 6 | 7 | عثرت على خطأ؟ 8 | ======================= 9 | إذا عثرت على أي خطأ تقني أو في الترجمة أرجو منك مراسلتي وإعلامي بالأمر على: schacon at gmail dot com. 10 | 11 | 12 | الترجمة 13 | ======================= 14 | هذه هي الترجمة العربية لكتاب Pro Git (احترف Git). يمكنك المساعدة في ترجمة الكتاب عن طريق الذهاب الى صفحة المشروع على GitHub. 15 | -------------------------------------------------------------------------------- /couchapp/.couchapprc: -------------------------------------------------------------------------------- 1 | {} -------------------------------------------------------------------------------- /couchapp/Makefile: -------------------------------------------------------------------------------- 1 | # TODO: research wildcard targets 2 | # TODO: DRY 3 | 4 | en: figures docs 5 | @for file in `ls ../en/*/*.markdown`; do \ 6 | filename=`basename -s .markdown $$file`; \ 7 | target=./_docs/$$filename; \ 8 | mkdir -p $$target; \ 9 | cp $$file $$target/body.markdown; \ 10 | echo $$filename > $$target/_id; \ 11 | done; 12 | 13 | de: figures docs 14 | @for file in `ls ../de/*/*.markdown`; do \ 15 | filename=`basename -s .markdown $$file`; \ 16 | target=./_docs/$$filename; \ 17 | mkdir -p $$target; \ 18 | cp $$file $$target/body.markdown; \ 19 | echo $$filename > $$target/_id; \ 20 | done; 21 | 22 | by: figures docs 23 | @for file in `ls ../by/*/*.markdown`; do \ 24 | filename=`basename -s .markdown $$file`; \ 25 | target=./_docs/$$filename; \ 26 | mkdir -p $$target; \ 27 | cp $$file $$target/body.markdown; \ 28 | echo $$filename > $$target/_id; \ 29 | done; 30 | 31 | # add your target language 32 | 33 | figures: 34 | mkdir -p _attachments/figures/ 35 | cp ../figures/* _attachments/figures/ 36 | 37 | docs: 38 | mkdir -p _docs 39 | 40 | clean: 41 | git clean -fdx 42 | -------------------------------------------------------------------------------- /couchapp/Readme.md: -------------------------------------------------------------------------------- 1 | # Chacon, a Markdown Viewer for the Progit book 2 | 3 | ## Usage 4 | 5 | $ cd couchapp 6 | $ make en 7 | $ couchapp push . progit 8 | $ open http://127.0.0.1:5984/progit/_design/chacon/_show/chapter/01-chapter1 9 | 10 | ## Requirements 11 | 12 | GNU Make 13 | 14 | Couchapp >= 0.6.0 15 | 16 | $ easy_install -U couchapp 17 | 18 | -------------------------------------------------------------------------------- /couchapp/_id: -------------------------------------------------------------------------------- 1 | _design/chacon 2 | -------------------------------------------------------------------------------- /couchapp/shows/chapter.js: -------------------------------------------------------------------------------- 1 | function(doc, req) { 2 | //!json templates 3 | send(templates.head); 4 | var markdown = require("vendor/markdown/showdown"); 5 | 6 | var resolve_figures = function (text) { 7 | return text.replace(/Insert ([^\.]+).png/g, function(all, figure) { 8 | return '
'; 9 | }); 10 | }; 11 | 12 | send(markdown.toHtml(resolve_figures(doc.body))); 13 | send(templates.foot); 14 | } 15 | -------------------------------------------------------------------------------- /couchapp/templates/foot.html: -------------------------------------------------------------------------------- 1 | 2 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /couchapp/templates/head.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Progit — By Scott Chacon 6 | 36 | 37 | 38 | 39 | 52 | -------------------------------------------------------------------------------- /couchapp/vendor/markdown/showdown.js: -------------------------------------------------------------------------------- 1 | /* 2 | A A L Source code at: 3 | T C A 4 | T K B 5 | */ 6 | 7 | var Showdown={}; 8 | Showdown.converter=function(){ 9 | var _1; 10 | var _2; 11 | var _3; 12 | var _4=0; 13 | this.makeHtml=function(_5){ 14 | _1=new Array(); 15 | _2=new Array(); 16 | _3=new Array(); 17 | _5=_5.replace(/~/g,"~T"); 18 | _5=_5.replace(/\$/g,"~D"); 19 | _5=_5.replace(/\r\n/g,"\n"); 20 | _5=_5.replace(/\r/g,"\n"); 21 | _5="\n\n"+_5+"\n\n"; 22 | _5=_6(_5); 23 | _5=_5.replace(/^[ \t]+$/mg,""); 24 | _5=_7(_5); 25 | _5=_8(_5); 26 | _5=_9(_5); 27 | _5=_a(_5); 28 | _5=_5.replace(/~D/g,"$$"); 29 | _5=_5.replace(/~T/g,"~"); 30 | return _5; 31 | }; 32 | var _8=function(_b){ 33 | var _b=_b.replace(/^[ ]{0,3}\[(.+)\]:[ \t]*\n?[ \t]*?[ \t]*\n?[ \t]*(?:(\n*)["(](.+?)[")][ \t]*)?(?:\n+|\Z)/gm,function(_c,m1,m2,m3,m4){ 34 | m1=m1.toLowerCase(); 35 | _1[m1]=_11(m2); 36 | if(m3){ 37 | return m3+m4; 38 | }else{ 39 | if(m4){ 40 | _2[m1]=m4.replace(/"/g,"""); 41 | } 42 | } 43 | return ""; 44 | }); 45 | return _b; 46 | }; 47 | var _7=function(_12){ 48 | _12=_12.replace(/\n/g,"\n\n"); 49 | var _13="p|div|h[1-6]|blockquote|pre|table|dl|ol|ul|script|noscript|form|fieldset|iframe|math|ins|del"; 50 | var _14="p|div|h[1-6]|blockquote|pre|table|dl|ol|ul|script|noscript|form|fieldset|iframe|math"; 51 | _12=_12.replace(/^(<(p|div|h[1-6]|blockquote|pre|table|dl|ol|ul|script|noscript|form|fieldset|iframe|math|ins|del)\b[^\r]*?\n<\/\2>[ \t]*(?=\n+))/gm,_15); 52 | _12=_12.replace(/^(<(p|div|h[1-6]|blockquote|pre|table|dl|ol|ul|script|noscript|form|fieldset|iframe|math)\b[^\r]*?.*<\/\2>[ \t]*(?=\n+)\n)/gm,_15); 53 | _12=_12.replace(/(\n[ ]{0,3}(<(hr)\b([^<>])*?\/?>)[ \t]*(?=\n{2,}))/g,_15); 54 | _12=_12.replace(/(\n\n[ ]{0,3}[ \t]*(?=\n{2,}))/g,_15); 55 | _12=_12.replace(/(?:\n\n)([ ]{0,3}(?:<([?%])[^\r]*?\2>)[ \t]*(?=\n{2,}))/g,_15); 56 | _12=_12.replace(/\n\n/g,"\n"); 57 | return _12; 58 | }; 59 | var _15=function(_16,m1){ 60 | var _18=m1; 61 | _18=_18.replace(/\n\n/g,"\n"); 62 | _18=_18.replace(/^\n/,""); 63 | _18=_18.replace(/\n+$/g,""); 64 | _18="\n\n~K"+(_3.push(_18)-1)+"K\n\n"; 65 | return _18; 66 | }; 67 | var _9=function(_19){ 68 | _19=_1a(_19); 69 | var key=_1c("
"); 70 | _19=_19.replace(/^[ ]{0,2}([ ]?\*[ ]?){3,}[ \t]*$/gm,key); 71 | _19=_19.replace(/^[ ]{0,2}([ ]?\-[ ]?){3,}[ \t]*$/gm,key); 72 | _19=_19.replace(/^[ ]{0,2}([ ]?\_[ ]?){3,}[ \t]*$/gm,key); 73 | _19=_1d(_19); 74 | _19=_1e(_19); 75 | _19=_1f(_19); 76 | _19=_7(_19); 77 | _19=_20(_19); 78 | return _19; 79 | }; 80 | var _21=function(_22){ 81 | _22=_23(_22); 82 | _22=_24(_22); 83 | _22=_25(_22); 84 | _22=_26(_22); 85 | _22=_27(_22); 86 | _22=_28(_22); 87 | _22=_11(_22); 88 | _22=_29(_22); 89 | _22=_22.replace(/ +\n/g,"
\n"); 90 | return _22; 91 | }; 92 | var _24=function(_2a){ 93 | var _2b=/(<[a-z\/!$]("[^"]*"|'[^']*'|[^'">])*>|)/gi; 94 | _2a=_2a.replace(_2b,function(_2c){ 95 | var tag=_2c.replace(/(.)<\/?code>(?=.)/g,"$1`"); 96 | tag=_2e(tag,"\\`*_"); 97 | return tag; 98 | }); 99 | return _2a; 100 | }; 101 | var _27=function(_2f){ 102 | _2f=_2f.replace(/(\[((?:\[[^\]]*\]|[^\[\]])*)\][ ]?(?:\n[ ]*)?\[(.*?)\])()()()()/g,_30); 103 | _2f=_2f.replace(/(\[((?:\[[^\]]*\]|[^\[\]])*)\]\([ \t]*()?[ \t]*((['"])(.*?)\6[ \t]*)?\))/g,_30); 104 | _2f=_2f.replace(/(\[([^\[\]]+)\])()()()()()/g,_30); 105 | return _2f; 106 | }; 107 | var _30=function(_31,m1,m2,m3,m4,m5,m6,m7){ 108 | if(m7==undefined){ 109 | m7=""; 110 | } 111 | var _39=m1; 112 | var _3a=m2; 113 | var _3b=m3.toLowerCase(); 114 | var url=m4; 115 | var _3d=m7; 116 | if(url==""){ 117 | if(_3b==""){ 118 | _3b=_3a.toLowerCase().replace(/ ?\n/g," "); 119 | } 120 | url="#"+_3b; 121 | if(_1[_3b]!=undefined){ 122 | url=_1[_3b]; 123 | if(_2[_3b]!=undefined){ 124 | _3d=_2[_3b]; 125 | } 126 | }else{ 127 | if(_39.search(/\(\s*\)$/m)>-1){ 128 | url=""; 129 | }else{ 130 | return _39; 131 | } 132 | } 133 | } 134 | url=_2e(url,"*_"); 135 | var _3e=""; 142 | return _3e; 143 | }; 144 | var _26=function(_3f){ 145 | _3f=_3f.replace(/(!\[(.*?)\][ ]?(?:\n[ ]*)?\[(.*?)\])()()()()/g,_40); 146 | _3f=_3f.replace(/(!\[(.*?)\]\s?\([ \t]*()?[ \t]*((['"])(.*?)\6[ \t]*)?\))/g,_40); 147 | return _3f; 148 | }; 149 | var _40=function(_41,m1,m2,m3,m4,m5,m6,m7){ 150 | var _49=m1; 151 | var _4a=m2; 152 | var _4b=m3.toLowerCase(); 153 | var url=m4; 154 | var _4d=m7; 155 | if(!_4d){ 156 | _4d=""; 157 | } 158 | if(url==""){ 159 | if(_4b==""){ 160 | _4b=_4a.toLowerCase().replace(/ ?\n/g," "); 161 | } 162 | url="#"+_4b; 163 | if(_1[_4b]!=undefined){ 164 | url=_1[_4b]; 165 | if(_2[_4b]!=undefined){ 166 | _4d=_2[_4b]; 167 | } 168 | }else{ 169 | return _49; 170 | } 171 | } 172 | _4a=_4a.replace(/"/g,"""); 173 | url=_2e(url,"*_"); 174 | var _4e="\""+_4a+"\"";"+_21(m1)+""); 184 | }); 185 | _4f=_4f.replace(/^(.+)[ \t]*\n-+[ \t]*\n+/gm,function(_52,m1){ 186 | return _1c("

"+_21(m1)+"

"); 187 | }); 188 | _4f=_4f.replace(/^(\#{1,6})[ \t]*(.+?)[ \t]*\#*\n+/gm,function(_54,m1,m2){ 189 | var _57=m1.length; 190 | return _1c(""+_21(m2)+""); 191 | }); 192 | return _4f; 193 | }; 194 | var _58; 195 | var _1d=function(_59){ 196 | _59+="~0"; 197 | var _5a=/^(([ ]{0,3}([*+-]|\d+[.])[ \t]+)[^\r]+?(~0|\n{2,}(?=\S)(?![ \t]*(?:[*+-]|\d+[.])[ \t]+)))/gm; 198 | if(_4){ 199 | _59=_59.replace(_5a,function(_5b,m1,m2){ 200 | var _5e=m1; 201 | var _5f=(m2.search(/[*+-]/g)>-1)?"ul":"ol"; 202 | _5e=_5e.replace(/\n{2,}/g,"\n\n\n"); 203 | var _60=_58(_5e); 204 | _60=_60.replace(/\s+$/,""); 205 | _60="<"+_5f+">"+_60+"\n"; 206 | return _60; 207 | }); 208 | }else{ 209 | _5a=/(\n\n|^\n?)(([ ]{0,3}([*+-]|\d+[.])[ \t]+)[^\r]+?(~0|\n{2,}(?=\S)(?![ \t]*(?:[*+-]|\d+[.])[ \t]+)))/g; 210 | _59=_59.replace(_5a,function(_61,m1,m2,m3){ 211 | var _65=m1; 212 | var _66=m2; 213 | var _67=(m3.search(/[*+-]/g)>-1)?"ul":"ol"; 214 | var _66=_66.replace(/\n{2,}/g,"\n\n\n"); 215 | var _68=_58(_66); 216 | _68=_65+"<"+_67+">\n"+_68+"\n"; 217 | return _68; 218 | }); 219 | } 220 | _59=_59.replace(/~0/,""); 221 | return _59; 222 | }; 223 | _58=function(_69){ 224 | _4++; 225 | _69=_69.replace(/\n{2,}$/,"\n"); 226 | _69+="~0"; 227 | _69=_69.replace(/(\n)?(^[ \t]*)([*+-]|\d+[.])[ \t]+([^\r]+?(\n{1,2}))(?=\n*(~0|\2([*+-]|\d+[.])[ \t]+))/gm,function(_6a,m1,m2,m3,m4){ 228 | var _6f=m4; 229 | var _70=m1; 230 | var _71=m2; 231 | if(_70||(_6f.search(/\n{2,}/)>-1)){ 232 | _6f=_9(_72(_6f)); 233 | }else{ 234 | _6f=_1d(_72(_6f)); 235 | _6f=_6f.replace(/\n$/,""); 236 | _6f=_21(_6f); 237 | } 238 | return "
  • "+_6f+"
    • \n"; 239 | }); 240 | _69=_69.replace(/~0/g,""); 241 | _4--; 242 | return _69; 243 | }; 244 | var _1e=function(_73){ 245 | _73+="~0"; 246 | _73=_73.replace(/(?:\n\n|^)((?:(?:[ ]{4}|\t).*\n+)+)(\n*[ ]{0,3}[^ \t\n]|(?=~0))/g,function(_74,m1,m2){ 247 | var _77=m1; 248 | var _78=m2; 249 | _77=_79(_72(_77)); 250 | _77=_6(_77); 251 | _77=_77.replace(/^\n+/g,""); 252 | _77=_77.replace(/\n+$/g,""); 253 | _77="
    "+_77+"\n
    "; 254 | return _1c(_77)+_78; 255 | }); 256 | _73=_73.replace(/~0/,""); 257 | return _73; 258 | }; 259 | var _1c=function(_7a){ 260 | _7a=_7a.replace(/(^\n+|\n+$)/g,""); 261 | return "\n\n~K"+(_3.push(_7a)-1)+"K\n\n"; 262 | }; 263 | var _23=function(_7b){ 264 | _7b=_7b.replace(/(^|[^\\])(`+)([^\r]*?[^`])\2(?!`)/gm,function(_7c,m1,m2,m3,m4){ 265 | var c=m3; 266 | c=c.replace(/^([ \t]*)/g,""); 267 | c=c.replace(/[ \t]*$/g,""); 268 | c=_79(c); 269 | return m1+""+c+""; 270 | }); 271 | return _7b; 272 | }; 273 | var _79=function(_82){ 274 | _82=_82.replace(/&/g,"&"); 275 | _82=_82.replace(//g,">"); 277 | _82=_2e(_82,"*_{}[]\\",false); 278 | return _82; 279 | }; 280 | var _29=function(_83){ 281 | _83=_83.replace(/(\*\*|__)(?=\S)([^\r]*?\S[*_]*)\1/g,"$2"); 282 | _83=_83.replace(/(\*|_)(?=\S)([^\r]*?\S)\1/g,"$2"); 283 | return _83; 284 | }; 285 | var _1f=function(_84){ 286 | _84=_84.replace(/((^[ \t]*>[ \t]?.+\n(.+\n)*\n*)+)/gm,function(_85,m1){ 287 | var bq=m1; 288 | bq=bq.replace(/^[ \t]*>[ \t]?/gm,"~0"); 289 | bq=bq.replace(/~0/g,""); 290 | bq=bq.replace(/^[ \t]+$/gm,""); 291 | bq=_9(bq); 292 | bq=bq.replace(/(^|\n)/g,"$1 "); 293 | bq=bq.replace(/(\s*
    [^\r]+?<\/pre>)/gm,function(_88,m1){
294 | var pre=m1;
295 | pre=pre.replace(/^  /mg,"~0");
296 | pre=pre.replace(/~0/g,"");
297 | return pre;
298 | });
299 | return _1c("
    \n"+bq+"\n
    ");
300 | });
301 | return _84;
302 | };
303 | var _20=function(_8b){
304 | _8b=_8b.replace(/^\n+/g,"");
305 | _8b=_8b.replace(/\n+$/g,"");
306 | var _8c=_8b.split(/\n{2,}/g);
307 | var _8d=new Array();
308 | var end=_8c.length;
309 | for(var i=0;i=0){
312 | _8d.push(str);
313 | }else{
314 | if(str.search(/\S/)>=0){
315 | str=_21(str);
316 | str=str.replace(/^([ \t]*)/g,"
    ");
317 | str+="
    ";
318 | _8d.push(str);
319 | }
320 | }
321 | }
322 | end=_8d.length;
323 | for(var i=0;i=0){
325 | var _91=_3[RegExp.$1];
326 | _91=_91.replace(/\$/g,"$$$$");
327 | _8d[i]=_8d[i].replace(/~K\d+K/,_91);
328 | }
329 | }
330 | return _8d.join("\n\n");
331 | };
332 | var _11=function(_92){
333 | _92=_92.replace(/&(?!#?[xX]?(?:[0-9a-fA-F]+|\w+);)/g,"&");
334 | _92=_92.replace(/<(?![a-z\/?\$!])/gi,"<");
335 | return _92;
336 | };
337 | var _25=function(_93){
338 | _93=_93.replace(/\\(\\)/g,_94);
339 | _93=_93.replace(/\\([`*_{}\[\]()>#+-.!])/g,_94);
340 | return _93;
341 | };
342 | var _28=function(_95){
343 | _95=_95.replace(/<((https?|ftp|dict):[^'">\s]+)>/gi,"    $1");
344 | _95=_95.replace(/<(?:mailto:)?([-.\w]+\@[-a-z0-9]+(\.[-a-z0-9]+)*\.[a-z]+)>/gi,function(_96,m1){
345 | return _98(_a(m1));
346 | });
347 | return _95;
348 | };
349 | var _98=function(_99){
350 | function char2hex(ch){
351 | var _9b="0123456789ABCDEF";
352 | var dec=ch.charCodeAt(0);
353 | return (_9b.charAt(dec>>4)+_9b.charAt(dec&15));
354 | }
355 | var _9d=[function(ch){
356 | return "&#"+ch.charCodeAt(0)+";";
357 | },function(ch){
358 | return "&#x"+char2hex(ch)+";";
359 | },function(ch){
360 | return ch;
361 | }];
362 | _99="mailto:"+_99;
363 | _99=_99.replace(/./g,function(ch){
364 | if(ch=="@"){
365 | ch=_9d[Math.floor(Math.random()*2)](ch);
366 | }else{
367 | if(ch!=":"){
368 | var r=Math.random();
369 | ch=(r>0.9?_9d[2](ch):r>0.45?_9d[1](ch):_9d[0](ch));
370 | }
371 | }
372 | return ch;
373 | });
374 | _99=""+_99+"";
375 | _99=_99.replace(/">.+:/g,"\">");
376 | return _99;
377 | };
378 | var _a=function(_a3){
379 | _a3=_a3.replace(/~E(\d+)E/g,function(_a4,m1){
380 | var _a6=parseInt(m1);
381 | return String.fromCharCode(_a6);
382 | });
383 | return _a3;
384 | };
385 | var _72=function(_a7){
386 | _a7=_a7.replace(/^(\t|[ ]{1,4})/gm,"~0");
387 | _a7=_a7.replace(/~0/g,"");
388 | return _a7;
389 | };
390 | var _6=function(_a8){
391 | _a8=_a8.replace(/\t(?=\t)/g,"    ");
392 | _a8=_a8.replace(/\t/g,"~A~B");
393 | _a8=_a8.replace(/~B(.+?)~A/g,function(_a9,m1,m2){
394 | var _ac=m1;
395 | var _ad=4-_ac.length%4;
396 | for(var i=0;i<_ad;i++){
397 | _ac+=" ";
398 | }
399 | return _ac;
400 | });
401 | _a8=_a8.replace(/~A/g,"    ");
402 | _a8=_a8.replace(/~B/g,"");
403 | return _a8;
404 | };
405 | var _2e=function(_af,_b0,_b1){
406 | var _b2="(["+_b0.replace(/([\[\]\\])/g,"\\$1")+"])";
407 | if(_b1){
408 | _b2="\\\\"+_b2;
409 | }
410 | var _b3=new RegExp(_b2,"g");
411 | _af=_af.replace(_b3,_94);
412 | return _af;
413 | };
414 | var _94=function(_b4,m1){
415 | var _b6=m1.charCodeAt(0);
416 | return "~E"+_b6+"E";
417 | };
418 | };
419 | var conv = new Showdown.converter();
420 | exports.toHtml = conv.makeHtml;
421 | 


--------------------------------------------------------------------------------
/couchapp/vendor/mustache.js/mustache.js:
--------------------------------------------------------------------------------
  1 | /*
  2 |   Shameless port of http://github.com/defunkt/mustache
  3 |   by Jan Lehnardt ,
  4 |      Alexander Lang ,
  5 |      Sebastian Cohnen 
  6 | 
  7 |   Thanks @defunkt for the awesome code.
  8 | 
  9 |   See http://github.com/defunkt/mustache for more info.
 10 | */
 11 | 
 12 | var Mustache = function() {
 13 |   var Renderer = function() {};
 14 | 
 15 |   Renderer.prototype = {
 16 |     otag: "{{",
 17 |     ctag: "}}",
 18 |     pragmas: {},
 19 |     buffer: [],
 20 |     pragmas_implemented: {
 21 |       "IMPLICIT-ITERATOR": true
 22 |     },
 23 | 
 24 |     render: function(template, context, partials, in_recursion) {
 25 |       // fail fast
 26 |       if(template.indexOf(this.otag) == -1) {
 27 |         if(in_recursion) {
 28 |           return template;
 29 |         } else {
 30 |           this.send(template);
 31 |           return;
 32 |         }
 33 |       }
 34 | 
 35 |       if(!in_recursion) {
 36 |         this.buffer = [];
 37 |       }
 38 | 
 39 |       template = this.render_pragmas(template);
 40 |       var html = this.render_section(template, context, partials);
 41 |       if(in_recursion) {
 42 |         return this.render_tags(html, context, partials, in_recursion);
 43 |       }
 44 | 
 45 |       this.render_tags(html, context, partials, in_recursion);
 46 |     },
 47 | 
 48 |     /*
 49 |       Sends parsed lines
 50 |     */
 51 |     send: function(line) {
 52 |       if(line != "") {
 53 |         this.buffer.push(line);
 54 |       }
 55 |     },
 56 | 
 57 |     /*
 58 |       Looks for %PRAGMAS
 59 |     */
 60 |     render_pragmas: function(template) {
 61 |       // no pragmas
 62 |       if(template.indexOf(this.otag + "%") == -1) {
 63 |         return template;
 64 |       }
 65 | 
 66 |       var that = this;
 67 |       var regex = new RegExp(this.otag + "%([\\w_-]+) ?([\\w]+=[\\w]+)?"
 68 |         + this.ctag);
 69 |       return template.replace(regex, function(match, pragma, options) {
 70 |         if(!that.pragmas_implemented[pragma]) {
 71 |           throw({message: "This implementation of mustache doesn't understand the '"
 72 |             + pragma + "' pragma"});
 73 |         }
 74 |         that.pragmas[pragma] = {};
 75 |         if(options) {
 76 |           var opts = options.split("=");
 77 |           that.pragmas[pragma][opts[0]] = opts[1];
 78 |         }
 79 |         return "";
 80 |         // ignore unknown pragmas silently
 81 |       });
 82 |     },
 83 | 
 84 |     /*
 85 |       Tries to find a partial in the global scope and render it
 86 |     */
 87 |     render_partial: function(name, context, partials) {
 88 |       if(!partials || !partials[name]) {
 89 |         throw({message: "unknown_partial '" + name + "'"});
 90 |       }
 91 |       if(typeof(context[name]) != "object") {
 92 |         return partials[name];
 93 |       }
 94 |       return this.render(partials[name], context[name], partials, true);
 95 |     },
 96 | 
 97 |     /*
 98 |       Renders boolean and enumerable sections
 99 |     */
100 |     render_section: function(template, context, partials) {
101 |       if(template.indexOf(this.otag + "#") == -1) {
102 |         return template;
103 |       }
104 |       var that = this;
105 |       // CSW - Added "+?" so it finds the tighest bound, not the widest
106 |       var regex = new RegExp(this.otag + "\\#(.+)" + this.ctag +
107 |               "\\s*([\\s\\S]+?)" + this.otag + "\\/\\1" + this.ctag + "\\s*", "mg");
108 | 
109 |       // for each {{#foo}}{{/foo}} section do...
110 |       return template.replace(regex, function(match, name, content) {
111 |         var value = that.find(name, context);
112 |         if(that.is_array(value)) { // Enumerable, Let's loop!
113 |           return that.map(value, function(row) {
114 |             return that.render(content, that.merge(context,
115 |                     that.create_context(row)), partials, true);
116 |           }).join("");
117 |         } else if(value) { // boolean section
118 |           return that.render(content, context, partials, true);
119 |         } else {
120 |           return "";
121 |         }
122 |       });
123 |     },
124 | 
125 |     /*
126 |       Replace {{foo}} and friends with values from our view
127 |     */
128 |     render_tags: function(template, context, partials, in_recursion) {
129 |       // tit for tat
130 |       var that = this;
131 | 
132 |       var new_regex = function() {
133 |         return new RegExp(that.otag + "(=|!|>|\\{|%)?([^\/#]+?)\\1?" +
134 |           that.ctag + "+", "g");
135 |       };
136 | 
137 |       var regex = new_regex();
138 |       var lines = template.split("\n");
139 |        for (var i=0; i < lines.length; i++) {
140 |          lines[i] = lines[i].replace(regex, function(match, operator, name) {
141 |            switch(operator) {
142 |              case "!": // ignore comments
143 |                return match;
144 |              case "=": // set new delimiters, rebuild the replace regexp
145 |                that.set_delimiters(name);
146 |                regex = new_regex();
147 |                return "";
148 |              case ">": // render partial
149 |                return that.render_partial(name, context, partials);
150 |              case "{": // the triple mustache is unescaped
151 |                return that.find(name, context);
152 |              default: // escape the value
153 |                return that.escape(that.find(name, context));
154 |            }
155 |          }, this);
156 |          if(!in_recursion) {
157 |            this.send(lines[i]);
158 |          }
159 |        }
160 | 
161 |        if(in_recursion) {
162 |          return lines.join("\n");
163 |        }
164 |     },
165 | 
166 |     set_delimiters: function(delimiters) {
167 |       var dels = delimiters.split(" ");
168 |       this.otag = this.escape_regex(dels[0]);
169 |       this.ctag = this.escape_regex(dels[1]);
170 |     },
171 | 
172 |     escape_regex: function(text) {
173 |       // thank you Simon Willison
174 |       if(!arguments.callee.sRE) {
175 |         var specials = [
176 |           '/', '.', '*', '+', '?', '|',
177 |           '(', ')', '[', ']', '{', '}', '\\'
178 |         ];
179 |         arguments.callee.sRE = new RegExp(
180 |           '(\\' + specials.join('|\\') + ')', 'g'
181 |         );
182 |       }
183 |     return text.replace(arguments.callee.sRE, '\\$1');
184 |     },
185 | 
186 |     /*
187 |       find `name` in current `context`. That is find me a value
188 |       from the view object
189 |     */
190 |     find: function(name, context) {
191 |       name = this.trim(name);
192 |       if(typeof context[name] === "function") {
193 |         return context[name].apply(context);
194 |       }
195 |       if(context[name] !== undefined) {
196 |         return context[name];
197 |       }
198 |       // silently ignore unkown variables
199 |       return "";
200 |     },
201 | 
202 |     // Utility methods
203 | 
204 |     /*
205 |       Does away with nasty characters
206 |     */
207 |     escape: function(s) {
208 |       return ((s == null) ? "" : s).toString().replace(/[&"<>\\]/g, function(s) {
209 |         switch(s) {
210 |           case "&": return "&";
211 |           case "\\": return "\\\\";;
212 |           case '"': return '\"';;
213 |           case "<": return "<";
214 |           case ">": return ">";
215 |           default: return s;
216 |         }
217 |       });
218 |     },
219 | 
220 |     /*
221 |       Merges all properties of object `b` into object `a`.
222 |       `b.property` overwrites a.property`
223 |     */
224 |     merge: function(a, b) {
225 |       var _new = {};
226 |       for(var name in a) {
227 |         if(a.hasOwnProperty(name)) {
228 |           _new[name] = a[name];
229 |         }
230 |       };
231 |       for(var name in b) {
232 |         if(b.hasOwnProperty(name)) {
233 |           _new[name] = b[name];
234 |         }
235 |       };
236 |       return _new;
237 |     },
238 | 
239 |     // by @langalex, support for arrays of strings
240 |     create_context: function(_context) {
241 |       if(this.is_object(_context)) {
242 |         return _context;
243 |       } else if(this.pragmas["IMPLICIT-ITERATOR"]) {
244 |         var iterator = this.pragmas["IMPLICIT-ITERATOR"].iterator || ".";
245 |         var ctx = {};
246 |         ctx[iterator] = _context;
247 |         return ctx;
248 |       }
249 |     },
250 | 
251 |     is_object: function(a) {
252 |       return a && typeof a == "object";
253 |     },
254 | 
255 |     is_array: function(a) {
256 |       return Object.prototype.toString.call(a) === '[object Array]';
257 |     },
258 | 
259 |     /*
260 |       Gets rid of leading and trailing whitespace
261 |     */
262 |     trim: function(s) {
263 |       return s.replace(/^\s*|\s*$/g, "");
264 |     },
265 | 
266 |     /*
267 |       Why, why, why? Because IE. Cry, cry cry.
268 |     */
269 |     map: function(array, fn) {
270 |       if (typeof array.map == "function") {
271 |         return array.map(fn);
272 |       } else {
273 |         var r = [];
274 |         var l = array.length;
275 |         for(var i=0;i Wenn du mit einem Kapitel anfangen willst, "checke" es dadurch "aus", daß
10 |    du eine neue, leere Datei dafür anlegst, commitest und pushst.
11 | 
12 | Andere sehen dann, daß jemand bereits an diesem Kapitel arbeitet, und wir
13 | können hoffentlich doppelte Arbeit vermeiden.
14 | 
15 | Mailingliste:
16 | 
17 | Unsere Mailingliste ist hier: http://groups.google.com/group/progit-german
18 | 
19 | Wenn du an der deutschen Übersetzung von Progit arbeitest oder arbeiten willst, sag uns dort bitte bescheid, damit wir uns alle eventuelle doppelte Arbeit sparen :)
20 | 
21 | Workflow:
22 | 
23 | Wir arbeiten lokal in einem working/topic branch. Du kannst diesen branch nach Github pushen, wenn du willst, aber du solltest die working branches anderer nicht ändern.
24 | 
25 | Der branch, in den wir unsere gemeinsame Arbeit an der deutschen Übersetzung synchronisieren (mergen) ist der branch translation-de. Wir verwenden dazu nicht master, damit es einfacher ist master in Sync mit Scott's Repository zu halten.
26 | 
27 | git clone git@github.com:svenfuchs/progit.git
28 | 
29 | # Lokalen working branch anlegen, darin arbeiten, rebasen und pushen
30 | git checkout --track -b translation-de origin/translation-de
31 | git checkout -b work
32 | # ... Änderungen in diesem branch vornehmen ...
33 | git checkout translation-de
34 | git pull
35 | git checkout work
36 | git rebase translation-de
37 | # ggf. Konflikte beheben:
38 | # git mergetool
39 | # git rebase --continue
40 | git checkout translation-de
41 | git merge work
42 | git push
43 | 
44 | # Möglicherweise vorhandene Änderungen bei uns auf progit/master rebasen
45 | git remote add progit git://github.com/progit/progit.git
46 | git fetch progit
47 | git rebase progit/master
48 | # ggf. Konflikte beheben:
49 | # git mergetool
50 | # git rebase --continue
51 | git push
52 | 
53 | # Änderungen aus translation-de auf master rebasen
54 | git checkout master
55 | git pull
56 | git checkout translation-de
57 | git rebase master
58 | # ggf. Konflikte beheben:
59 | # git mergetool
60 | # git rebase --continue
61 | git checkout master
62 | git merge translation-de
63 | git push
64 | 
65 | Einige Erfahrungen:
66 | 
67 | * Es macht Sinn, möglichst oft zu rebasen und zu pushen, damit man nicht
68 |   allzuviele Konflikte erhält.
69 | 
70 | * Wenn du andere wirklich nerven willst, dann nimm Rechtschreibkorrekturen an
71 |   ihren noch unfertigen Übersetzungen vor. Rechtschreibung und Feinheiten in
72 |   Formulierungen zu korrigieren, daß man zahlreiche winzige Änderungen in
73 |   verschiedenen Versionen von ganzen Absätzen zusammenführen muß. Das kostet
74 |   massiv Zeit und lohnt sich einfach nicht, solange die Übersetzung noch nicht
75 |   fertig ist.
76 | 
77 | * Es macht Sinn, die Englische Fassung des Textes zu kopieren und dann Absatz
78 |   für Absatz die Übersetzung einzufügen, das Original aber vorläufig stehen zu
79 |   lassen. Das macht es leichter, in späteren Iterationen mit dem Original zu
80 |   vergleichen.
81 | 
82 | * Ich fand es nützlich in Iterationen zu arbeiten, um möglichst die ganze Zeit
83 |   mentail im gleichen "Modus" zu bleiben. In meiner ersten Iteration habe ich
84 |   das Original so zügig wie möglich übersetzt. Schwierigere Stellen oder Worte
85 |   habe ich lediglich mit "xxx" markiert und bin weitergegangen. In der zweiten
86 |   Iteration habe ich dann mehr auf den Stil geachtet, umformuliert und die
87 |   (wenigen) zuvor ausgelassenen Stellen nach-übersetzt.
88 | 
89 | * Ich arbeite wesentlich effizienter, wenn ich mir eine Timebox setze und in
90 |   mich in dieser Zeit von nichts anderem ablenken lasse. Das funktioniert für
91 |   mich z.B. gut morgens in der U-Bahn auf dem Weg ins Office und nachmittags
92 |   wieder zurück. Dort kann ich etwa eine halbe Stunde lang ungestört
93 |   übersetzen - eine Zeitspanne, die ich als angenehm empfinde.
94 | 
95 | 


--------------------------------------------------------------------------------
/de/STATUS:
--------------------------------------------------------------------------------
 1 | = Status
 2 | 
 3 | | Kapitel | Iteration | Status | Bearbeiter                 |
 4 | | 1       | 1         | x      | Sven Fuchs                 |
 5 | | 2       | 1         | x      | Sven Fuchs                 |
 6 | | 3       | 1         | wip    | Fritzek, Florian Breisch   |
 7 | | 4       | 1         | wip    | Sebastian Ohm              |
 8 | | 5       | 1         | x      | Sven Fuchs                 |
 9 | | 6       | 1         | wip    | Sven Fuchs                 |
10 | | 7       | 1         | wip    | Markus Holtmanns           |
11 | | 8       | 1         | x      | Jean Pierre Wenzel         |
12 | | 9       | 1         | x      | Sven Fuchs                 |
13 | 
14 | = Legende
15 | 
16 | == Status
17 | 
18 | x        - vollständig
19 | wip      - wird bearbeitet (work in progress)
20 | pausiert - teilweise fertig, derzeit nicht in Bearbeitung, kann von anderen 
21 |            übernommen werden
22 | 
23 | == Iteration / Prozeß
24 | 
25 | Übersetzung (pro Kapitel)
26 | Iteration 1: grobe Übersetzung, unklare Stellen markiert
27 | Iteration 2: markierte Stellen vervollständigen, Formulierungen glätten
28 | 
29 | Überarbeitung (gesamt)
30 | Iteration 3: Formulierungen, Stil und Schreibung vereinheitlichen
31 | Iteration 4: Feinschliff, Übersetzung von Grafiken
32 | 
33 | 
34 | Um die Status Tabelle neu zu formatieren eignet sich das Makro "Align Table 
35 | Cells" aus dem Cucumber TextMate Bundle hervorragend :)
36 | 


--------------------------------------------------------------------------------
/ebooks/cover.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/ebooks/cover.png


--------------------------------------------------------------------------------
/epub/ProGit.css:
--------------------------------------------------------------------------------
 1 | ul {
 2 | 	margin: 20px;
 3 | }
 4 | 
 5 | ol {
 6 | 	margin: 20px;
 7 | }
 8 | 
 9 | body pre {
10 | 	margin: 10px;
11 | 	font-weight: bold;
12 | }
13 | 
14 | body pre2 {
15 | 	background-color: silver;
16 | 	padding: 10px;
17 | 	border-top-style: solid;
18 | 	border-left-style: solid;
19 | 	border-left-width: 1px;
20 | 	border-top-width: 1px;
21 | 	overflow-x: auto; /* Use horizontal scroller if needed; for Firefox 2, not needed in Firefox 3 */
22 | 	white-space: pre-wrap; /* css-3 */
23 | 	white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
24 | 	white-space: -pre-wrap; /* Opera 4-6 */
25 | 	white-space: -o-pre-wrap; /* Opera 7 */
26 |  /* width: 99%; */
27 | 	 word-wrap: break-word; /* Internet Explorer 5.5+ */
28 |  }


--------------------------------------------------------------------------------
/epub/title.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/epub/title.png


--------------------------------------------------------------------------------
/es/NOTES:
--------------------------------------------------------------------------------
 1 | # Palabras que me crean regomeyo
 2 | 
 3 | - Backport: No encuentro una traducción adecuada.
 4 | - Branch/Branching: Lo traduzco como *rama*/*ramificación*, pero pongo entre () el término original.
 5 | - Checkin: No encuentro una traducción adecuada.
 6 | - Checkout: No encuentro una traducción adecuada.
 7 | - Checksum: Lo traduzco como *suma de comprobación* a regañadientes, pongo entre () el término original.
 8 | - Commit/Committed: Lo traduzco como *confirmar*/*confirmado*, pero pongo entre () el término original.
 9 | - Diff: Lo traduzco como *diferencia*.
10 | - Fork: Lo traduzco como *bifurcación*, pero pongo entre () el término original.
11 | - Hook: Lo traduzco como *gancho* a regañadientes, pongo entre () el término original.
12 | - Kernel: La traducción habitual es *núcleo*, así que la usaré.
13 | - Manpage: Lo traduzco como *página del manual*, pero pongo entre () el término original.
14 | - Merge: Lo traduzco como *unión*, pero pongo entre () el término original.
15 | - Rebase: No encuentro una traducción adecuada.
16 | - Pull: Lo traduzco como *recibir*, pero pongo entre () el término original. No quiero usar *descargar* o *bajar*, porque parece que hace referencia a entornos cliente/servidor.
17 | - Push: Lo traduzco como *mandar*, pero pongo entre () el término original. No quiero usar *subir*, porque parece que hace referencia a entornos cliente/servidor.
18 | - Remote: Lo traduzco como *repositorio remoto* o *remoto*.
19 | - Snapshot: Lo traduzco como *instantánea*.
20 | - Stage/Staged: Lo traduzco como *preparar*/*preparado*, pero pongo entre () el término original.
21 | - Staging area: Parece ser un término militar. Se refiere a una localización temporal donde se reúnen recursos antes de un ataque o invasión. Lo traduzco como *área de preparación*, pero pongo entre () el término original.
22 | - Track/Tracking: Lo traduzco como *seguir*/*seguimiento*.
23 | 
24 | 
25 | # Anotaciones sobre las anotaciones [afgomez]
26 | 
27 | - No creo que sea necesario poner entre parentesis los términos originales de "rama" y "unión". Es una traduccion lo suficientemente clara como para no necesitarlos.
28 | - A lo largo del texto se utilizan guiones '-' para indicar aclaraciones en el texto. En Español el signo correcto es la raya ('—', — en HTML), y debe ir siempre cerrado, por lo que se han modificado en el texto.
29 |   Más información: http://es.wikipedia.org/wiki/Raya_%28puntuaci%C3%B3n%29


--------------------------------------------------------------------------------
/es/README:
--------------------------------------------------------------------------------
1 | # Traducción al español (España)
2 | 
3 | Agradezco todo tipo de sugerencias y correcciones sobre mi traducción del libro Pro Git (http://progit.org/).
4 | 


--------------------------------------------------------------------------------
/es/glosario-Benzirpi.tab:
--------------------------------------------------------------------------------
 1 | fetch	recuperar
 2 | merge	fusionar, integrar
 3 | pull	recuperar e integrar
 4 | push	enviar, publicar
 5 | checkout	activar
 6 | rebase	reorganizar
 7 | staging area	área de preparación
 8 | snapshot	instantánea, estado o situación en un determinado momento puntual
 9 | commit	confirmación de cambios
10 | contributed	aportado por otros
11 | contribution	aportación
12 | maintaner	gestor de mantenimiento
13 | cherry-pick	entresacar
14 | blob	binary large object.... gran objeto binario
15 | 
16 | 


--------------------------------------------------------------------------------
/es/glosario.tab:
--------------------------------------------------------------------------------
 1 | fetch	recuperar
 2 | merge	fusionar, integrar
 3 | pull	recuperar e integrar
 4 | push	enviar, publicar
 5 | checkout	activar
 6 | rebase	reorganizar
 7 | staging area	área de preparación
 8 | snapshot	instantánea, estado o situación en un determinado momento puntual
 9 | commit	confirmación de cambios
10 | contributed	aportado por otros
11 | contribution	aportación
12 | maintaner	gestor de mantenimiento
13 | cherry-pick	entresacar
14 | blob	binary large object.... gran objeto binario
15 | 
16 | 


--------------------------------------------------------------------------------
/fi/NOTES:
--------------------------------------------------------------------------------
1 | Chapter 1 - Line 56: 		What is a proper finnish translation for the word "snapshot" in this case? Translated now as 'tilannekuvat'.
2 | 						Multiline: 	What is a proper finnish translation for the word "commit" in this case? Or do we need it, is permanen change (like it is now) enought to tell what it is about?
3 | 						Line 173:		Has a reference to chapter 9 with a translated name, make sure this name is not different when translating chapter 9.
4 | 						Chapter "The Three Stages" ("Kolme tilaa") has mentioned the "staged" word, what is correct translation for this in finnish? Now translated as "lavastettu".
5 | 						Line 230:		Translation for a word "Backports"


--------------------------------------------------------------------------------
/figures-dia/fig0101.dia:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures-dia/fig0101.dia


--------------------------------------------------------------------------------
/figures-dia/fig0102.dia:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures-dia/fig0102.dia


--------------------------------------------------------------------------------
/figures-dia/makeimages:
--------------------------------------------------------------------------------
 1 | #!/bin/bash
 2 | 
 3 | # Process all dia images to OUTFORMAT images.
 4 | # Usage: makeimages [lang]
 5 | # If localized image is available - uses it, else uses default one.
 6 | 
 7 | OUTFORMAT=png
 8 | 
 9 | path="."
10 | outpath="."
11 | 
12 | for img in `find $path -name "*.dia"`
13 | do
14 | 	infile=$img
15 | 	if [[ -n $1 ]]
16 | 	then
17 | 		tst=../$1/figures-dia/${img#$path/}
18 | 		if [[ -f $tst ]]
19 | 		then
20 | 			infile=$tst
21 | 		fi
22 | 	fi
23 | 	outfile=$outpath/${img%.dia}.$OUTFORMAT
24 | 	dia $infile -e $outfile
25 | done
26 | 


--------------------------------------------------------------------------------
/figures/18333fig0101-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0101-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0102-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0102-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0103-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0103-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0104-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0104-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0105-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0105-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0106-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0106-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0107-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0107-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0201-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0201-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0202-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0202-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0301-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0301-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0302-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0302-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0303-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0303-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0304-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0304-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0305-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0305-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0306-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0306-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0307-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0307-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0308-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0308-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0309-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0309-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0310-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0310-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0311-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0311-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0312-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0312-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0313-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0313-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0314-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0314-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0315-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0315-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0316-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0316-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0317-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0317-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0318-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0318-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0319-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0319-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0320-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0320-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0321-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0321-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0322-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0322-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0323-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0323-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0324-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0324-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0325-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0325-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0326-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0326-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0327-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0327-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0328-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0328-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0329-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0329-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0330-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0330-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0331-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0331-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0332-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0332-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0333-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0333-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0334-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0334-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0335-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0335-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0336-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0336-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0337-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0337-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0338-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0338-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0339-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0339-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0401-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0401-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0402-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0402-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0403-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0403-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0404-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0404-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0405-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0405-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0406-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0406-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0407-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0407-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0408-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0408-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0409-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0409-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0410-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0410-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0411-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0411-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0412-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0412-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0413-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0413-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0414-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0414-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0415-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0415-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0501-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0501-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0502-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0502-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0503-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0503-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0504-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0504-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0505-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0505-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0506-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0506-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0507-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0507-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0508-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0508-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0509-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0509-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0510-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0510-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0511-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0511-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0512-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0512-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0513-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0513-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0514-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0514-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0515-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0515-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0516-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0516-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0517-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0517-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0518-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0518-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0519-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0519-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0520-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0520-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0521-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0521-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0522-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0522-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0523-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0523-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0524-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0524-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0525-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0525-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0526-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0526-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0527-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0527-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0601-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0601-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0701-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0701-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0702-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0702-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0703-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0703-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0901-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0901-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0902-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0902-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0903-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0903-tn.png


--------------------------------------------------------------------------------
/figures/18333fig0904-tn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/figures/18333fig0904-tn.png


--------------------------------------------------------------------------------
/fr/NOTES.fr-fr.markdown:
--------------------------------------------------------------------------------
  1 | Notes on the french translation process
  2 | =======================================
  3 |   
  4 | These notes document the process of translating the book into
  5 | french. This is mostly about the choice of words and expressions and
  6 | should not be of any interest to non-french readers or translators.
  7 |   
  8 | Lexique
  9 | =======
 10 |   
 11 | Repository
 12 | ----------
 13 |   
 14 |   Dépôt
 15 |   
 16 | Check in
 17 | --------
 18 |   
 19 |   Dépôt
 20 |   
 21 | To check in
 22 | -----------
 23 |   
 24 |   Déposer, mettre en dépôt, faire un dépôt.
 25 |   
 26 |   Ex.
 27 |     To check a file in => Déposer un fichier
 28 |     When checking a directory in [...] => Lorsqu'on met un repertoire en dépôt
 29 |   
 30 | Check out
 31 | ---------
 32 |   
 33 |   Retrait
 34 |   
 35 | To check out
 36 | ------------
 37 |   
 38 |   Retirer, récupérer (parfois rapatrier est une bonne alternative)
 39 |   
 40 | To commit
 41 | ---------
 42 |   
 43 |   Consigner
 44 |   
 45 | Stage area
 46 | ----------
 47 |   
 48 |   Zone d'attente
 49 |   
 50 | To stage
 51 | --------
 52 |   
 53 |   Mettre en attente
 54 |   
 55 |   Eviter _mettre en zone d'attente_
 56 |   
 57 | To unstage
 58 | ----------
 59 |   
 60 |   
 61 |   
 62 | Change
 63 | ------
 64 |   
 65 |   Modification (à préférer à changement)
 66 |   
 67 | stash
 68 | -----
 69 |   
 70 |   Remise
 71 |   
 72 | To stash
 73 | --------
 74 |   
 75 |   Remiser
 76 |   
 77 | Checksum
 78 | --------
 79 |   
 80 |   Somme de contrôle
 81 |   
 82 | Hash
 83 | ----
 84 |   
 85 |   Empreinte
 86 |   
 87 |   Alternatives: signature, hachage (correct mais à éviter)
 88 |   
 89 | Workflow
 90 | --------
 91 |   
 92 |   Processus
 93 |   
 94 |   Alternative: scénario
 95 |   
 96 | Snapshot
 97 | --------
 98 |   
 99 |   Instantané
100 |   
101 |   Alternative: image, parfois, le choix de la traduction litérale 'photographie' est supérieur (rare)
102 |   
103 | Diff
104 | ----
105 |   
106 |   Diff
107 |   
108 | To track
109 | --------
110 |   
111 |   Suivre
112 |   
113 | untracked
114 | ---------
115 |   
116 |   non-suivi
117 |   
118 | unmodified
119 | ----------
120 |   
121 |   non-modifié
122 |   
123 | To update
124 | ---------
125 |   
126 |   Mettre à jour
127 |   
128 | 


--------------------------------------------------------------------------------
/fr/glossaire-git.adoc:
--------------------------------------------------------------------------------
  1 | Glossaire de Git
  2 | ================
  3 | 
  4 | :Auteur: Emmanuel Trillaud 
  5 | :Email: 
  6 | :Date: 11/02/10 15:04 
  7 | :Revision: 2
  8 | 
  9 | Glossaire de l'outil de gestion de version Git créé à partir des traductions de
 10 | 
 11 | * git-gui, http://repo.or.cz/w/git-gui.git[Sources]
 12 | * gitk, http://git.kernel.org/?p=gitk/gitk.git;a=summary[Sources]
 13 | * du « Git Community Book » http://book.git-scm.com/[en], http://alx.github.com/gitbook/[fr] et 
 14 | * du livre « Progit » http://progit.org/book/[en]
 15 | 
 16 | Autre doc utile
 17 | 
 18 | * gitglossary(7)
 19 | 
 20 | Convention du glossaire
 21 | un « ? » à côté d'un mot signifie que la traduction proposée est discutable
 22 | « ctx » sert à indiquer un contexte
 23 | 
 24 | .Objets Git
 25 | * object -> objet
 26 |   - loose object ->
 27 | * Tree (Object) -> Arbre
 28 | * Commit (Objet) -> Commit
 29 | * Tag (Object) -> Tag
 30 |   - annotated -> tag annoté
 31 |   - ligthweigt tag -> tag léger
 32 | * Blob (Object) -> Blob
 33 | * refs -> références
 34 | 
 35 | .Spécifique à Git
 36 | * HEAD -> fichier HEAD, HEAD
 37 | * detached (head)->
 38 | * refspec -> spécification de références
 39 | * Plumbing -> plomberie
 40 | * Porcelain -> porcelaine
 41 | * index ->
 42 | * staging area ->
 43 | 
 44 | .VCS
 45 | * version -> révision
 46 | * working directory -> répertoire de travail
 47 | * working tree -> arbre de travail
 48 | * snapshot -> instantané
 49 | * history -> historique/journal
 50 | * fast-forward (ctx merge) -> avance rapide
 51 |   - fast-forward reference -> avance rapide
 52 | * repository -> dépôt
 53 | * diff -> diff
 54 | * patch -> patch
 55 | 
 56 | .SHA-1
 57 | * hash -> empreinte
 58 | * checksum -> somme de contrôle
 59 | * digest -> empreinte
 60 | * key -> clé
 61 | * SHA-1 -> empreinte SHA-1
 62 | 
 63 | .Actions/Commandes
 64 | Si le mot fait référence à la commande, on ne traduit pas. Par si on fait
 65 | référence à l'action, on peut traduire.
 66 | 
 67 | * checkout ->
 68 | * branch(es) -> branches
 69 |   - remote branches -> branche distante
 70 | * remote -> distant
 71 |   a remote -> un dépôt distant
 72 | * pull -> tirer ("retirer" est peut-être mieux)
 73 | * fetch -> récupérer
 74 | * push -> pousser (pourquoi pas "publier")
 75 | * stash -> (gitbook propose "remiser"), planquer
 76 | * add -> ajouter
 77 | * log -> journal
 78 | * gc ->
 79 |  - garbage collector -> ramasse-miette
 80 | * reset -> réinitialiser
 81 |  - hard reset ->
 82 |  - soft reset ->
 83 |  - mixed reset ->
 84 | * bisect -> bissecter
 85 | * archive -> archiver
 86 | * cherry-pick -> sélectionner (a été préféré à "cueillir")
 87 | * cherry-picking -> sélection (préféré à "cueillette")
 88 | * clean -> nettoyer
 89 | * clone -> clôner
 90 | * To merge (a branch) -> fusionner
 91 | * To merge (a change) -> incorporer
 92 |  - a merge -> une fusion
 93 | * to diff ->
 94 | * rebase -> rebaser
 95 | * revert  -> défaire
 96 | * packfile ->
 97 | * to pack -> compacter
 98 | * topic branch -> branche thématique
 99 | 
100 | .Divers
101 | * hex -> hexa
102 | * hook ->
103 | * namespace -> espace de noms
104 | * Content-addressable filesystem -> système de fichier adressable par le contenu
105 | * DAG(Direct Acyclic Graph) -> Graphe orienté acyclique
106 | * pattern -> motif
107 | 


--------------------------------------------------------------------------------
/it/03-git-branching/01-chapter3.markdown:
--------------------------------------------------------------------------------
1 | # Git Branching #
2 | 
3 | Praticamente ogni VCS ha un suo modo di supportare il branching. Branching significa distanziarsi dal flusso principale di sviluppo continuando a lavorare senza correre il rischio di fare pasticci sul flusso principale. In molti strumenti VCS questo è un processo in alcuni termini costoso, spesso richiede la creazione di una nuova copia della directory del codice sorgente che in grandi progetti può richiedere molto tempo.
4 | 
5 | Molte persone fanno riferimento al modello di branching di Git per indicare la "killer feature", e questo certamente separa Git dagli altri VCS. Perchè è così speciale? Git crea branch in modo incredibilmente semplice e leggero, permettendo operazioni di branching praticamente istantanee come lo sono anche i passaggi da un branch ad un altro. Diversamente da molti altri VCS, Git incoraggia un workflow che sfrutta branch e merge frequentemente, anche molte volte al giorno. Capire e padroneggiare questa funzionalità mette a disposizione uno strumento potente ed unico e può letteralmente modificare il modo in cui si lavora.


--------------------------------------------------------------------------------
/it/04-git-server/01-chapter4.markdown:
--------------------------------------------------------------------------------
 1 | # Git sul server #
 2 | 
 3 | A questo punto, si dovrebbe essere in grado di fare la maggior parte dei compiti quotidiani che si devono fare con Git. Tuttavia, al fine di fare una qualsiasi collaborazione in Git, bisogna avere un repository remoto Git. Anche se è possibile tecnicamente spingere modifiche e tirare le modifiche da repository individuali, procedere in questo modo è sconsigliato, perché se non si sta attenti, ci si può confondere abbastanza facilmente riguardo a quello su cui si sta lavorando. Inoltre, si vuole che i collaboratori siano in grado di accedere al repository, anche se il computer non è in linea - avere un repository comune più affidabile spesso è utile. Pertanto, il metodo preferito per collaborare con qualcuno, è quello di creare un repository intermedio a cui avere accesso entrambi e spingere e tirare da questo. Si farà riferimento a questo repository come un "server Git"; ma si noterà che in genere ospitare un repository Git ha bisogno di una piccola quantità di risorse, quindi raramente c'è bisogno di usare un intero server per esso.
 4 | 
 5 | Avviare un server Git è semplice. In primo luogo, si sceglie quali protocolli si desidera utilizzare per comunicare con il server. La prima sezione di questo capitolo descriverà i protocolli disponibili con i pro e i contro di ciascuno. La sezione seguente spiegherà alcune impostazioni tipiche nell'utilizzo di questi protocolli e come utilizzarle nel proprio server. Infine, se non si hanno problemi a fare ospitare il proprio codice su un server di qualcun altro e se si vuole dedicare del tempo alla creazione e al mantenimento di un proprio server, si prenderà in considerazione qualche opzione per l'hosting.
 6 | 
 7 | Se non si ha interesse a gestire il proprio server, è possibile passare all'ultima sezione del capitolo per vedere alcune opzioni per la creazione di un account hosting e poi saltare al capitolo successivo, dove si discutono i flussi in ingresso e uscita in un ambiente distribuito per il controllo del codice sorgente. 
 8 | 
 9 | Un repository remoto è in genere un _bare repository_ cioè un repository Git che non ha la cartella di lavoro. Essendo che il repository viene utilizzato solo come un punto di collaborazione, non c'è ragione di avere uno snapshot estratto dal disco, ma solo i dati Git. In termini più semplici, un repository nudo è il contenuto della cartella `.git` del progetto e nient'altro.
10 | 
11 | ## I protocolli ##
12 | 
13 | Git può utilizzare quattro importanti protocolli di rete per trasferire i dati: locale, Secure Shell (SSH), Git, e HTTP. Qui vedremo cosa sono e in quali circostanze di base si vuole (o non si vuole) usarli.
14 | 
15 | E' importante notare che, ad eccezione dei protocolli HTTP, tutti questi richiedono che Git sia installato e funzionante sul server.
16 | 
17 | ### Il protocollo locale ###
18 | 
19 | Quello più semplice è il _protocollo locale_, in cui il repository remoto è in un'altra cartella sul disco. Questo è spesso utilizzato se ciascuno nel team ha accesso a un file system condiviso come l'NFS, o, nel caso meno probabile tutti accedano allo stesso computer. Quest'ultimo caso non è l'ideale, perché tutte le istanze del codice nel repository risiederebbero sullo stesso computer, facendo diventare molto più probabile una perdita catastrofica dei dati.
20 | 
21 | Se si dispone di un filesystem montato in comune, allora si può clonare, fare un push, e un pull da un repository locale basato su file. Per clonare un repository come questo o per aggiungerne uno da remoto per un progetto esistente, utilizzare il percorso al repository come URL. Ad esempio, per clonare un repository locale, è possibile eseguire qualcosa di simile a questo:
22 | 
23 | 	$ git clone /opt/git/project.git
24 | 
25 | O questo:
26 | 
27 | 	$ git clone file:///opt/git/project.git
28 | 
29 | Git funziona in modo leggermente diverso se si specifica esplicitamente `file://` all'inizio dell'URL. Se si specifica il percorso, Git tenta di utilizzare hardlink o copia direttamente i file necessari. Se si specifica file://`, Git abilita i processi che utilizza normalmente per trasferire i dati su una rete, il che è generalmente un metodo molto meno efficace per il trasferimento dei dati. La ragione principale per specificare il prefisso `file://`  è quella in cui si desidera una copia pulita del repository, lasciando fuori riferimenti estranei o oggetti - in genere dopo l'importazione da un altro sistema di controllo della versione o qualcosa di simile (si veda il Capitolo 9 relativo ai task per la manutenzione). Qui verrà usato il percorso normale, perché così facendo è quasi sempre più veloce.
30 | 
31 | Per aggiungere un repository locale a un progetto Git esistente, è possibile eseguire qualcosa di simile a questo:
32 | 
33 | 	$ git remote add local_proj /opt/git/project.git
34 | 
35 | Quindi, si possono eseguire push e pull da remoto come se si stesse lavorando su una rete.
36 | 
37 | #### I Pro ####
38 | 
39 | I pro dei repository basati su file sono che sono semplici e che utilizzano i permessi sui file e l'accesso alla rete già esistenti. Se si ha già un filesystem condiviso a cui l'intero team ha accesso, la creazione di un repository è molto facile. Si mette la copia nuda del repository da qualche parte dove tutti hanno un accesso condiviso e si impostano i permessi di lettura / scrittura, come si farebbe per qualsiasi altra cartella condivisa. Si vedrà proprio per questo scopo come esportare una copia nuda del repository nella sezione successiva, "Installare Git su un server."
40 | 
41 | Questa è anche una interessante possibilità per recuperare rapidamente il lavoro dal repository di qualcun altro. Se una persona e un collega stanno lavorando allo stesso progetto e vogliono recuperare qualcosa da fuori, lanciare un comando tipo `git pull /home/john/project` è spesso più facile che fare push su un server remoto e poi fare pull per scaricarlo.
42 | 
43 | #### I Contro ####
44 | 
45 | Il contro di questo metodo è che l'accesso condiviso è generalmente più difficile da impostare e raggiungere da più postazioni, che un normale accesso di rete. Se si vuole fare push dal computer portatile quando si è a casa, bisogna montare il disco remoto, che può essere difficoltoso e lento rispetto ad un accesso si rete.
46 | 
47 | E' anche importante ricordare che questa non è necessariamente l'opzione più veloce, se si utilizzando un mount condiviso di qualche tipo. Un repository locale è veloce solo se si dispone di un accesso veloce ai dati. Un repository su NFS è spesso più lento di un repository su SSH sullo stesso server, permettendo a Git di andare con dischi locali su ogni sistema.
48 | 


--------------------------------------------------------------------------------
/it/06-git-tools/01-chapter6.markdown:
--------------------------------------------------------------------------------
  1 | # Git Tools #
  2 | 
  3 | Fin'ora sono stati imparati la maggior parte dei comandi giornalieri a i
  4 | workflow che potrebbero essere necessari a gestire e mantenere un repository Git
  5 | per il controllo del codice sorgente.
  6 | Sono state compiute le attività di base per il tracciamento e il commit dei
  7 | file, ed è stato sfruttato il potere della *staging area* e argomenti leggeri il
  8 | *branching* (ramificazione) e il *merge*.
  9 | 
 10 | Ora verrà esplorato un numero di cose veramente potenti che Git può fare che non
 11 | vengono necessariamente usate di base quotidianamente ma che potrebbero servire
 12 | ad un certo punto.
 13 | 
 14 | ## Selezione della revisione ##
 15 | 
 16 | Git permette di specificare determinati *commit* o una serie di *commit* in
 17 | diversi modi.
 18 | Non sono necessariamente evidenti ma può essere d'aiuto conoscerli.
 19 | 
 20 | ### Singola revisione ###
 21 | 
 22 | E' possibile ovviamente riferirsi a un *commit* tramite l'hash SHA-1 che viene
 23 | dato, ma ci sono modi più alla portata degli umani per riferirsi ai *commit*.
 24 | Questa sezione delinea i diversi modi con cui ci si può riferire ad un singolo
 25 | commit.
 26 | 
 27 | ### SHA breve ###
 28 | 
 29 | Git è abbastanza intelligente da capire a quale *commit* ci si riferisce se si
 30 | fornisce i primi caratteri, purché il codice SHA-1 sia di almeno quattro
 31 | caratteri e univoco - solo un oggetto nel *repository* corrente inizia con quel
 32 | SHA-1 parziale.
 33 | 
 34 | Per esempio, per vedere uno specifico *commit*, supponiamo che venga eseguito un
 35 | comando 'git log' e venga identificato un *commit* dove sono state aggiunte
 36 | certe funzionalità:
 37 | 
 38 | 	$ git log
 39 | 	commit 734713bc047d87bf7eac9674765ae793478c50d3
 40 | 	Author: Scott Chacon 
 41 | 	Date:   Fri Jan 2 18:32:33 2009 -0800
 42 | 
 43 | 	    fixed refs handling, added gc auto, updated tests
 44 | 
 45 | 	commit d921970aadf03b3cf0e71becdaab3147ba71cdef
 46 | 	Merge: 1c002dd... 35cfb2b...
 47 | 	Author: Scott Chacon 
 48 | 	Date:   Thu Dec 11 15:08:43 2008 -0800
 49 | 
 50 | 	    Merge commit 'phedders/rdocs'
 51 | 
 52 | 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 53 | 	Author: Scott Chacon 
 54 | 	Date:   Thu Dec 11 14:58:32 2008 -0800
 55 | 
 56 | 	    added some blame and merge stuff
 57 | 
 58 | In questo caso, scegliamo '1c002dd....' Se viene eseguito 'git show' su quel
 59 | *commit*, i seguenti comandi sono equivalenti (assumendo che le versioni più
 60 | corte siano univoche):            
 61 | 
 62 | 	$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 63 | 	$ git show 1c002dd4b536e7479f
 64 | 	$ git show 1c002d
 65 | 
 66 | Git riesce a capire una corta, univoca abbreviazione del valore SHA-1. Se viene
 67 | passato '--abbrev-commit' al comando 'git-log', l'*output* userà valori più
 68 | corti ma li manterrà unici; in maniera predefinita utilizza sette caratteri ma
 69 | se necessario ne userà di più per mantenere il codice SHA-1 univoco:
 70 | 
 71 | 	$ git log --abbrev-commit --pretty=oneline
 72 | 	ca82a6d changed the version number
 73 | 	085bb3b removed unnecessary test code
 74 | 	a11bef0 first commit
 75 | 
 76 | Generalmente, da otto a dieci caratteri sono più che sufficienti per essere
 77 | univoci all'interno di un progetto.
 78 | Uno dei progetti Git più grandi, il kernel Linux, inizia a necessitare 12
 79 | caratteri, dei 40 possibili, per rimanere univoco.
 80 | 
 81 | ### Una breve nota su SHA-1 ###
 82 | 
 83 | Un sacco di gente si preoccupa ad un certo punto che, per una qualche casualità,
 84 | potrebbe avere due oggetti nel proprio *repository* che abbiano lo stesso hash
 85 | SHA-1. Cosa accadrebbe a quel punto?
 86 | 
 87 | Se capita di fare il *commit* di un oggetto che ha lo stesso SHA-1 di un oggetto
 88 | precedente nel proprio *repository*, Git noterà il precedente oggetto già
 89 | presente nel database Git e lo riterrà già scritto.
 90 | Provando ad ottenere informazioni su quell'oggetto nuovamente ad un certo punto,
 91 | verranno sempre restituiti i dati del primo oggetto.
 92 | 
 93 | Ad ogni modo, è necessario essere consapevoli di quanto ridicolmente improbabile
 94 | sia questo scenario. Il codice SHA-1 riassunto è di 20 bytes o 160 bits. Il
 95 | numero casuale di oggetti necessari per assicurare un 50% di una singola
 96 | collisione è di circa 2^80 (la formula per determinare la probabilità di
 97 | collisione è `p = (n(n-1)/2) * (1/2^160))`. 2^80 è 1.2 x 10^24 o un milione di
 98 | miliardi di miliardi. E' 1,200 volte il numero di granelli di sabbia sulla
 99 | terra.
100 | 
101 | Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione
102 | SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra stessero
103 | programmando, e ogni secondo, ognuno stesse producendo codice che fosse
104 | equivalente all'intera storia del kernel Linux (1 milione di oggetti Git) e se
105 | lo stesse caricando su un enorme *repository* Git, ci vorrebbero 5 anni per
106 | contenere abbastanza oggetti in quel *repository* da avere il 50% di possibilità
107 | di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che
108 | ogni membro del team venga attaccato e ucciso dai lupi in situazioni
109 | indipendenti durante la stessa notte.
110 | 
111 | ### Riferimenti al *branch* ###
112 | 
113 | La strada più diretta per specificare un *commit* richiede che punti ad un
114 | riferimento di un *branch*. A quel punto potrebbe essere usato il nome del
115 | *branch* in qualsiasi comando Git che richiede un oggetto *commit* o un valore
116 | SHA-1. Per esempio, se si vuole mostrare l'ultimo oggetto *commit* di un
117 | *branch*, i seguenti comandi sono equivalenti, ammesso che il *branch* 'topic1'
118 | punti a 'ca82a6d':
119 | 
120 | 	$ git show ca82a6dff817ec66f44342007202690a93763949
121 | 	$ git show topic1
122 | 
123 | Se si vuole vedere a quale specifico SHA un *branch* punta, o se si vuole vedere
124 | a cosa si riduce ognuno di questi esempi in termini di SHA, si può usare un
125 | *plumbing tool* di Git chiamato 'rev-parse'. Nel Capitolo 9 ci sono più informazioni
126 | sui *plumbing tool*; sostanzialmente, 'rev-parse' esiste per operazioni di basso
127 | livello e non è concepito per essere usato in operazioni quotidiane. Comunque,
128 | può essere d'aiuto a volte quanto c'è bisogno di vedere cosa succede realmente.
129 | A quel punto si può lanciare 'rev-parse' sul proprio *branch*.
130 | 
131 | 	$ git rev-parse topic1
132 | 	ca82a6dff817ec66f44342007202690a93763949
133 | 
134 | ### RefLog ###
135 | 
136 | Una delle cose che Git fa mentre si lavora è tenere un reflog - un log sui
137 | riferimenti di *HEAD* e *branch* degli ultimi mesi.
138 | 
139 | E' possibile vedere il reflog usando il comando 'git reflog':
140 | 
141 | 	$ git reflog
142 | 	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
143 | 	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
144 | 	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
145 | 	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
146 | 	95df984... HEAD@{4}: commit: # This is a combination of two commits.
147 | 	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
148 | 	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
149 | 
150 | Ogni volta che il *branch* è aggiornato, Git registra l'informazione in questa
151 | lista temporanea. Si possono specificare anche *commit* più vecchi. Se si vuole
152 | vedere il quinto valore precedente della *HEAD* del proprio *repository*, si può
153 | usare il riferimento '@{n}' che si vede nel *output* di reflog:
154 | 
155 | 	$ git show HEAD@{5}
156 | 
157 | Si può anche usare questa sintassi per vedere dove era un *branch* una certa
158 | quantità di tempo fa. Per esempio, per vedere dov'era il 'master' *branch* ieri,
159 | si può scrivere:
160 | 
161 | 	$ git show master@{yesterday}
162 | 
163 | Questo mostra dove era il *branch* ieri. Questa tecnica funziona solo per i dati
164 | che sono ancora nel *reflog*, non è possibile usarla per vedere *commit* più
165 | vecchi di qualche mese.
166 | 
167 | Per vedere le informazioni del *reflog* formattate come il '*git log*', si può
168 | lanciare il comando 'git log -g':
169 | 
170 | 	$ git log -g master
171 | 	commit 734713bc047d87bf7eac9674765ae793478c50d3
172 | 	Reflog: master@{0} (Scott Chacon )
173 | 	Reflog message: commit: fixed refs handling, added gc auto, updated 
174 | 	Author: Scott Chacon 
175 | 	Date:   Fri Jan 2 18:32:33 2009 -0800
176 | 
177 | 	    fixed refs handling, added gc auto, updated tests
178 | 
179 | 	commit d921970aadf03b3cf0e71becdaab3147ba71cdef
180 | 	Reflog: master@{1} (Scott Chacon )
181 | 	Reflog message: merge phedders/rdocs: Merge made by recursive.
182 | 	Author: Scott Chacon 
183 | 	Date:   Thu Dec 11 15:08:43 2008 -0800
184 | 
185 | 	    Merge commit 'phedders/rdocs'
186 | 
187 | E' importante notare che l'informazione del *reflog* è strettamente locale - è
188 | un log di cosa è stato fatto nel proprio *repository*. I riferimenti non saranno
189 | uguali nella copia del *repository* tenuta da qualcun altro.
190 | Lanciare 'git show HEAD@{2.months-ago}' funzionerà solo se il progetto è stato
191 | clonato almeno due mesi fa - se è stato clonato cinque minuti prima non verrà
192 | restituito alcun risultato.
193 | 
194 | ### Riferimenti di discendenza ###
195 | 
196 | L'altro modo per specificare un *commit* è attraverso la sua discendenza. Se
197 | viene posizionato un `^` alla fine di un riferimento, Git lo interpreta come il
198 | genitore di quel determinato *commit*.
199 | Supponiamo che si guardi la lista delle modifiche effettuate nel progetto:
200 | 
201 | 	$ git log --pretty=format:'%h %s' --graph
202 | 	* 734713b fixed refs handling, added gc auto, updated tests
203 | 	*   d921970 Merge commit 'phedders/rdocs'
204 | 	|\  
205 | 	| * 35cfb2b Some rdoc changes
206 | 	* | 1c002dd added some blame and merge stuff
207 | 	|/  
208 | 	* 1c36188 ignore *.gem
209 | 	* 9b29157 add open3_detach to gemspec file list
210 | 
211 | E' possibile vedere il precedente *commit* specificando `HEAD^`, che significa
212 | "il genitore di HEAD":
213 | 
214 | 	$ git show HEAD^
215 | 	commit d921970aadf03b3cf0e71becdaab3147ba71cdef
216 | 	Merge: 1c002dd... 35cfb2b...
217 | 	Author: Scott Chacon 
218 | 	Date:   Thu Dec 11 15:08:43 2008 -0800
219 | 
220 | 	    Merge commit 'phedders/rdocs'
221 | 
222 | Si può anche specificare un numero dopo `^` - per esempio, `d921970^2` significa
223 | "il secondo genitore di d921870." Questa sintassi è utile per fare il *merge* di
224 | *commit* che hanno più di un genitore.
225 | Il primo genitore è il *branch* dove ci si trova al momento del *merge*, e il
226 | secondo è il *commit* sul *branch* di cui è stato fatto il *merge*:
227 | 
228 | 	$ git show d921970^
229 | 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
230 | 	Author: Scott Chacon 
231 | 	Date:   Thu Dec 11 14:58:32 2008 -0800
232 | 
233 | 	    added some blame and merge stuff
234 | 
235 | 	$ git show d921970^2
236 | 	commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
237 | 	Author: Paul Hedderly 
238 | 	Date:   Wed Dec 10 22:22:03 2008 +0000
239 | 
240 | 	    Some rdoc changes
241 | 
242 | Un altro modo per specificare la discendenza è `~`. Anche questo si riferisce al
243 | primo genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota
244 | quando viene specificato un numero.
245 | `HEAD~2` significa "il primo genitore del primo genitore", o "il nonno" -
246 | attraversa i primi genitori il numero di volte specificato. Per esempio, nella
247 | lista mostrata precedentemente, `HEAD~3` sarebbe
248 | 
249 | 	$ git show HEAD~3
250 | 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
251 | 	Author: Tom Preston-Werner 
252 | 	Date:   Fri Nov 7 13:47:59 2008 -0500
253 | 
254 | 	    ignore *.gem
255 | 
256 | Potrebbe essere anche scritto come `HEAD^^^`, che è sempre il primo genitore del
257 | primo genitore del primo genitore:
258 | 
259 | 	$ git show HEAD^^^
260 | 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
261 | 	Author: Tom Preston-Werner 
262 | 	Date:   Fri Nov 7 13:47:59 2008 -0500
263 | 
264 | 	    ignore *.gem
265 | 
266 | E' possibile anche combinare queste sintassi - si può prendere il secondo
267 | genitore del precedente riferimento (assumendo che si tratti di un *merge
268 | commit*) usando `HEAD~3^2`, e così via.            
269 | 


--------------------------------------------------------------------------------
/it/07-customizing-git/01-chapter7.markdown:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/it/07-customizing-git/01-chapter7.markdown


--------------------------------------------------------------------------------
/ja/01-introduction/01-chapter1.markdown:
--------------------------------------------------------------------------------
  1 | # 使い始める #
  2 | 
  3 | この章は、Gitを使い始めることに関してになります。まずはバージョン管理システムの背景に触れ、その後にGitをあなたのシステムで動かす方法、そしてGitで作業を始めるための設定方法について説明します。この章を読み終えるころには、なぜGitが広まっているか、なぜGitを使うべきなのか、それをするための準備が全て整っているだろうということを、あなたはきっと理解しているでしょう。
  4 | 
  5 | ## バージョン管理に関して ##
  6 | 
  7 | バージョン管理とは何でしょうか、また、なぜそれを気にする必要があるのでしょうか？
  8 | バージョン管理とは、変更を一つのファイル、もしくは時間を通じたファイルの集合に記録するシステムで、そのため後で特定バージョンを呼び出すことができます。現実にはコンピューター上のほとんどあらゆるファイルのタイプでバージョン管理を行なう事ができますが、本書の中の例では、バージョン管理されるファイルとして、ソフトウェアのソースコードを利用します。
  9 | 
 10 | もしあなたが、グラフィックス・デザイナー、もしくはウェブ・デザイナーであって、（あなたが最も確実に望んでいるであろう）画像もしくはレイアウトの全てのバージョンを管理したいのであれば、バージョン管理システム（VCS）はとても賢く利用できるものです。それは、ファイルを以前の状態まで戻し、プロジェクト丸ごとを以前の状態に戻し、時間を通じた変化を比較し、誰が最後に問題を引き起こすだろう何かを修正したか、誰が、何時、課題を導入したかを知り、それ以上のことを可能にします。VCSを使うということはまた、一般的に、何かをもみくちゃにするか、ファイルを失うとしても、簡単に復活させることができることを意味します。加えて、とても僅かな諸経費で、それら全てを得ることができます。
 11 | 
 12 | ### ローカル・バージョン管理システム ###
 13 | 
 14 | 多くの人々の選り抜きのバージョン管理手法は、他のディレクトリ（もし彼らが賢いのであれば、恐らく日時が書かれたディレクトリ）にファイルをコピーするというものです。このアプローチは、とても単純なためにすごく一般的ですが、信じられない間違い傾向もあります。どのディレクトリにいるのか忘れやすいですし、偶然に間違ったファイルに書き込んだり、意図しないファイルに上書きしたりします。
 15 | 
 16 | この問題を扱うため、大昔にプログラマは、バージョン管理下で全ての変更をファイルに保持するシンプルなデータベースを持つ、ローカルなバージョン管理システムを開発しました（図1-1参照）。
 17 | 
 18 | Insert 18333fig0101.png 
 19 | 図1-1. ローカル・バージョン管理図解
 20 | 
 21 | もっとも有名なVCSツールの一つが、RCSと呼ばれるシステムでした。今日でも依然として多くのコンピューターに入っています。人気のMac OS Xオペレーティング・システムさえも、開発者ツールをインストールしたときは、rcsコマンドを含みます。このツールは基本的に、ディスク上に特殊フォーマットで、一つの変更からもう一つの変更へのパッチ（これはファイル間の差分です）の集合を保持することで稼動します。そういうわけで、全てのパッチを積み上げることで、いつかは、あらゆる時点の、あらゆるファイルのように見えるものを再生成する事ができます。
 22 | 
 23 | ### 集中バージョン管理システム ###
 24 | 
 25 | 次に人々が遭遇した大きな問題は、他のシステムの開発者と共同制作をする必要があることです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。CVSやSubversion、Perforceのような、これらのシステムは、全てのバージョン管理されたファイルと、その中央の場所からファイルをチェック・アウトする多数のクライアントを含む単一のサーバーを持ちます。長年の間、これはバージョン管理の標準となって来ました（図1-2参照）。
 26 | 
 27 | Insert 18333fig0102.png 
 28 | 図1-2. 集中バージョン管理図解
 29 | 
 30 | この構成は、特にローカルVCSと比較して、多くの利点を提供します。例えば、全ての人は、プロジェクトのその他の全ての人々が何をしているのか、一定の程度は知っています。管理者は、誰が何をできるのかについて、きめ細かい統制手段を持ちます。このため、一つのCVCSを管理するということは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。
 31 | 
 32 | しかしながら、この構成はまた、深刻な不利益も持ちます。もっとも明白なのは、中央サーバーで発生する単一障害点です。もし、そのサーバーが1時間の間停止すると、その1時間の間は誰も全く、共同作業や、彼らが作業を進めている全てに対してバージョン変更の保存をすることができなくなります。もし中央データベースがのっているハードディスクが破損し、適切なバックアップが保持されていないとすると、人々が偶然にローカル・マシンに持っていた幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）を除いた、プロジェクト全体の履歴を失うことになります。ローカルVCSシステムも、これと同じ問題に悩まされます。つまり、単一の場所にプロジェクトの全体の履歴を持っているときはいつでも、全てを失う事を覚悟することになります。
 33 | 
 34 | ### 分散バージョン管理システム ###
 35 | 
 36 | ここから分散バージョン管理システム(DVCs)に入ります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングします。故にどのサーバーが故障したとして、故障したサーバーを介してそれらのDVCSが共同作業をしていたとしても、あらゆるクライアント・リポジトリは修復のためにサーバーにコピーして戻す事ができます。そのサーバーを介してコラボレーションしていたシステムは, どれか一つのクライアントのリポジトリからサーバー復旧の為バックアップをコピーすることができます. 全てのチェックアウトは、実は全データの完全バックアップなのです(図1-3を参照)。
 37 | 
 38 | Insert 18333fig0103.png 
 39 | 図1-3. 分散バージョン管理システムの図解
 40 | 
 41 | そのうえ、これらのDVCSの多くは、 連携する複数のリモート・リポジトリを扱いながら大変よく機能するため、同一のプロジェクト内において、同時に異なった方法で、異なる人々のグループと共同作業が可能です。このことは、集中システムでは不可能であった階層モデルのような、幾つかの様式のワークフローを始めることを許します。
 42 | 
 43 | ## Git略史 ##
 44 | 
 45 | 人生における多くの素晴らしい出来事のように、Gitはわずかな創造的破壊と熱烈な論争から始まりました。Linuxカーネルは、非常に巨大な範囲のオープンソース・ソフトウェア・プロジェクトの一つです。Linuxカーネル保守の大部分の期間（1991-2002）の間は、このソフトウェアに対する変更は、パッチとアーカイブしたファイルとして次々にまわされていました。2002年に、Linuxカーネル・プロジェクトはプロプライエタリのDVCSであるBitKeeperを使い始めました。
 46 | 
 47 | 2005年に、Linuxカーネルを開発していたコミュニティと、BitKeeperを開発していた営利企業との間の協力関係が崩壊して、課金無しの状態が取り消されました。これは、Linux開発コミュニティ（と、特にLinuxの作者のLinus Torvalds）に、BitKeeperを利用している間に学んだ幾つかの教訓を元に、彼ら独自のツールの開発を促しました。新しいシステムの目標の幾つかは、次の通りでした：
 48 | 
 49 | *	スピード
 50 | *	シンプルな設計
 51 | *	ノンリニア開発(数千の並列ブランチ)への強力なサポート
 52 | *	完全な分散
 53 | *	Linux カーネルのような大規模プロジェクトを(スピードとデータサイズで)効率的に取り扱い可能
 54 | 
 55 | 2005年のその誕生から、Gitは使いやすく発展・成熟してきており、さらにその初期の品質を維持しています。とても高速で、巨大プロジェクトではとても効率的で、ノンリニア開発のためのすごい分岐システム（branching system）を備えています（第3章参照）。
 56 | 
 57 | ## Gitの基本 ##
 58 | 
 59 | では、要するにGitとは何なのでしょうか。これは、Gitを吸収するには重要な節です。なぜならば、もしGitが何かを理解し、Gitがどうやって稼動しているかの根本を理解できれば、Gitを効果的に使う事が恐らくとても容易になるからです。
 60 | Gitを学ぶときは、SubversionやPerforceのような他のVCSsに関してあなたが恐らく知っていることは、意識しないでください。このツールを使うときに、ちょっとした混乱を回避することに役立ちます。Gitは、ユーザー・インターフェイスがとてもよく似ているのにも関わらず、それら他のシステムとは大きく異なって、情報を格納して取り扱います（訳者注：「取り扱う」の部分はthinksなので、「見なします」と訳す方が原語に近い）。これらの相違を理解する事は、Gitを扱っている間の混乱を、防いでくれるでしょう。
 61 | 
 62 | ### スナップショットで、差分ではない ###
 63 | 
 64 | Gitと他のVCS (Subversionとその類を含む)の主要な相違は、Gitのデータについての考え方です。概念的には、他のシステムのほとんどは、情報をファイルを基本とした変更のリストとして格納します。これらのシステム（CVS、Subversion、Perforce、Bazaar等々）は、図1-4に描かれているように、システムが保持しているファイルの集合と、時間を通じてそれぞれのファイルに加えられた変更の情報を考えます。
 65 | 
 66 | Insert 18333fig0104.png 
 67 | 図1-4. 他のシステムは、データをそれぞれのファイルの基本バージョンへの変更として格納する傾向があります。
 68 | 
 69 | Gitは、この方法ではデータを考えたり、格納しません。代わりに、Gitはデータをミニ・ファイルシステムのスナップショットの集合のように考えます。Gitで全てのコミット（訳注：commitとは変更を記録・保存するGitの操作。詳細は後の章を参照）をするとき、もしくはプロジェクトの状態を保存するとき、Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り（訳者注：意訳）、そのスナップショットへの参照を格納するのです。効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。Gitは、むしろデータを図1-5のように考えます。
 70 | 
 71 | Insert 18333fig0105.png 
 72 | 図1-5. Gitは時間を通じたプロジェクトのスナップショットとしてデータを格納します。
 73 | 
 74 | これが、Gitと類似の全ての他のVCSsとの間の重要な違いです。ほとんどの他のシステムが以前の世代から真似してきた、ほとんど全てのバージョン管理のやり方（訳者注：aspectを意訳）を、Gitに見直させます。これは、Gitを、単純にVCSと言うより、その上に組み込まれた幾つかの途方も無くパワフルなツールを備えたミニ・ファイルシステムにしています。このやり方でデータを考えることで得られる利益の幾つかを、第3章のGit branchingを扱ったときに探求します。
 75 | 
 76 | ### ほとんど全ての操作がローカル ###
 77 | 
 78 | Gitのほとんどの操作は、ローカル・ファイルと操作する資源だけ必要とします。大体はネットワークの他のコンピューターからの情報は必要ではありません。ほとんどの操作がネットワーク遅延損失を伴うCVCSに慣れているのであれば、もっさりとしたCVCSに慣れているのであれば、このGitの速度は神業のように感じるでしょう（訳者注：直訳は「このGitの側面はスピードの神様がこの世のものとは思えない力でGitを祝福したと考えさせるでしょう」）。プロジェクトの履歴は丸ごとすぐそこのローカル・ディスクに保持しているので、大概の操作はほぼ瞬時のように見えます。
 79 | 
 80 | 例えば、プロジェクトの履歴を閲覧するために、Gitはサーバーに履歴を取得しに行って表示する必要がありません。直接にローカル・データベースからそれを読むだけです。これは、プロジェクトの履歴をほとんど即座に知るということです。もし、あるファイルの現在のバージョンと、そのファイルの1ヶ月前の間に導入された変更点を知りたいのであれば、Gitは、遠隔のサーバーに差分を計算するように問い合わせたり、ローカルで差分を計算するために遠隔サーバーからファイルの古いバージョンを持ってくる代わりに、1か月前のファイルを調べてローカルで差分の計算を行なえます。
 81 | 
 82 | これはまた、オフラインであるか、VPNから切り離されていたとしても、出来ない事は非常に少ないことを意味します。もし、飛行機もしくは列車にに乗ってちょっとした仕事をしたいとしても、アップロードするためにネットワーク接続し始めるまで、楽しくコミットできます。もし、帰宅してVPNクライアントを適切に作動させられないとしても、さらに作業ができます。多くの他のシステムでは、それらを行なう事は、不可能であるか苦痛です。例えばPerforceにおいては、サーバーに接続できないときは、多くの事が行なえません。SubversionとCVSにおいては、ファイルの編集はできますが、データベースに変更をコミットできません（なぜならば、データベースがオフラインだからです）。このことは巨大な問題に思えないでしょうが、実に大きな違いを生じうることに驚くでしょう。
 83 | 
 84 | ### Gitは完全性を持つ ###
 85 | 
 86 | Gitの全てのものは、格納される前にチェックサムが取られ、その後、そのチェックサムで照合されます。これは、Gitがそれに関して感知することなしに、あらゆるファイルの内容を変更することが不可能であることを意味します。この機能は、Gitの最下層に組み込まれ、またGitの哲学に不可欠です。Gitがそれを感知できない状態で、転送中に情報を失う、もしくは壊れたファイルを取得することはありません。
 87 | 
 88 | Gitがチェックサム生成に用いる機構は、SHA-1ハッシュと呼ばれます。これは、16進数の文字（0-9とa-f）で構成された40文字の文字列で、ファイルの内容もしくはGit内のディレクトリ構造を元に計算されます。SHA-1ハッシュは、このようなもののように見えます:
 89 | 
 90 | 	24b9da6552252987aa493b52f8696cd6d3b00373
 91 | 
 92 | Gitはハッシュ値を大変よく利用するので、Gitのいたるところで、これらのハッシュ値を見ることでしょう。事実、Gitはファイル名ではなく、ファイル内容のハッシュ値によってアドレスが呼び出されるGitデータベースの中に全てを格納しています。
 93 | 
 94 | ### Gitは通常はデータを追加するだけ ###
 95 | 
 96 | Gitで行動するとき、ほとんど全てはGitデータベースにデータを追加するだけです。システムにいかなる方法でも、UNDO不可能なこと、もしくはデータを消させることをさせるのは、大変難しいです。あらゆるVCSと同様に、まだコミットしていない変更は失ったり、台無しにできたりします。しかし、スナップショットをGitにコミットした後は、特にもし定期的にデータベースを他のリポジトリにプッシュ（訳注：pushはGitで管理するあるリポジトリのデータを、他のリポジトリに転送する操作。詳細は後の章を参照）していれば、変更を失うことは大変難しくなります。
 97 | 
 98 | 激しく物事をもみくちゃにする危険なしに試行錯誤を行なえるため、これはGitの利用を喜びに変えます。Gitがデータをどのように格納しているのかと失われたように思えるデータをどうやって回復できるのかについての、より詳細な解説に関しては、第9章の"Under the Covers"を参照してください。
 99 | 
100 | ### 三つの状態 ###
101 | 
102 | 今、注意してください。もし学習プロセスの残りをスムーズに進めたいのであれば、これはGitに関して覚えておく主要な事です。Gitは、ファイルが帰属する、コミット済、修正済、ステージ済の、三つの主要な状態を持ちます。コミット済は、ローカル・データベースにデータが安全に格納されていることを意味します。修正済は、ファイルに変更を加えていますが、データベースにそれがまだコミットされていないことを意味します。ステージ済は、次のスナップショットのコミットに加えるために、現在のバージョンの修正されたファイルに印をつけている状態を意味します。
103 | 
104 | このことは、Gitプロジェクト（訳者注：ディレクトリ内）の、Gitディレクトリ、作業ディレクトリ、ステージング・エリアの三つの主要な部分（訳者注：の理解）に導きます。
105 | 
106 | Insert 18333fig0106.png 
107 | 図1-6. 作業ディレクトリ、ステージング・エリア、Gitディレクトリ
108 | 
109 | Gitディレクトリは、プロジェクトのためのメタデータ（訳者注：Gitが管理するファイルやディレクトリなどのオブジェクトの要約）とオブジェクトのデータベースがあるところです。これは、Gitの最も重要な部分で、他のコンピューターからリポジトリをクローン（訳者注：コピー元の情報を記録した状態で、Gitリポジトリをコピーすること）したときに、コピーされるものです。
110 | 
111 | 作業ディレクトリは、プロジェクトの一つのバージョンの単一チェックアウトです。これらのファイルはGitディレクトリの圧縮されたデータベースから引き出されて、利用するか修正するためにディスクに配置されます。
112 | 
113 | ステージング・エリアは、普通はGitディレクトリに含まれる、次のコミットに何が含まれるかに関しての情報を蓄えた一つの単純なファイルです。ときどきインデックスのように引き合いにだされますが、ステージング・エリアとして呼ばれることが基本になりつつあります。
114 | 
115 | 基本的なGitのワークフローは、このような風に進みます：
116 | 
117 | 1. 作業ディレクトリのファイルを修正します。
118 | 2. 修正されたファイルのスナップショットをステージング・エリアに追加して、ファイルをステージします。
119 | 3. コミットします。（訳者注：Gitでは）これは、ステージング・エリアにあるファイルを取得し、永久不変に保持するスナップショットとしてGitディレクトリに格納することです。
120 | 
121 | もしファイルの特定のバージョンがGitディレクトリの中にあるとしたら、コミット済だと見なされます。もし修正されていて、ステージング・エリアに加えられていれば、ステージ済です。そして、チェックアウトされてから変更されましたが、ステージされていないとするなら、修正済です。第2章では、これらの状態と、どうやってこれらを利用をするか、もしくは完全にステージ化部分を省略するかに関してより詳しく学習します。
122 | 
123 | ## Gitのインストール ##
124 | 
125 | 少しGitを使う事に入りましょう。何よりも最初に、Gitをインストールしなければなりません。幾つもの経路で入手することができ、主要な二つの方法のうちの一つはソースからインストールすることで、もう一つはプラットフォームに応じて存在するパッケージをインストールすることです。
126 | 
127 | ### ソースからのインストール ###
128 | 
129 | もし可能であれば、もっとも最新のバージョンを入手できるので、一般的にソースからGitをインストールするのが便利です。Gitのそれぞれのバージョンは、実用的なユーザー・インターフェイスの向上が含まれており、もしソースからソフトウェアをコンパイルすることに違和感を感じないのであれば、最新バージョンを入手することは、大抵は最も良い経路になります。また、多くのLinuxディストリビューションがとても古いパッケージを収録している事は良くあることであり、最新のディストリビューションを使っているか、バックポート（訳者注：最新のパッケージを古いディストリビューションで使えるようにする事）をしていない限りは、ソースからのインストールがベストな選択になるでしょう。
130 | 
131 | Gitをインストールするためには、Gitが依存するライブラリーである、curl、zlib、openssl、expat、libiconvを入手する必要があります。例えば、もし（Fedoraなどで）yumか（Debianベースのシステムなどで）apt-getが入ったシステムを使っているのであれば、これらのコマンドの一つを依存対象の全てをインストールするのに使う事ができます：
132 | 
133 | 	$ yum install curl-devel expat-devel gettext-devel \
134 | 	  openssl-devel zlib-devel
135 | 
136 | 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
137 | 	  libz-dev libssl-dev
138 | 	
139 | 全ての必要な依存対象を持っているのであれば、先に進んでGitのウェブサイトから最新版のスナップショットを持ってくる事ができます：
140 | 
141 | 	http://git-scm.com/download
142 | 	
143 | そして、コンパイルしてインストールします：
144 | 
145 | 	$ tar -zxf git-1.6.0.5.tar.gz
146 | 	$ cd git-1.6.0.5
147 | 	$ make prefix=/usr/local all
148 | 	$ sudo make prefix=/usr/local install
149 | 
150 | また、Gitのインストール後、アップデートでGitを通して最新版のGitを得ることができます。
151 | 
152 | 	$ git clone git://git.kernel.org/pub/scm/git/git.git
153 | 	
154 | ### Linuxにインストール ###
155 | 
156 | バイナリのインストーラーを通じてLinux上にGitをインストールしたいのであれば、大抵はディストリビューションに付属する基本的なパッケージ・マネジメント・ツールを使って、それを行なう事ができます。もしFedoraを使っているのであれば、yumを使う事が出来ます：
157 | 
158 | 	$ yum install git-core
159 | 
160 | もしくは、もしUbuntuのようなDebianベースのディストリュビューションを使っているのであれば、apt-getをやってみましょう：
161 | 
162 | 	$ apt-get install git-core
163 | 
164 | ### Macにインストール ###
165 | 
166 | MacにGitをインストールするには2つの簡単な方法があります。もっとも簡単な方法は、グラフィカルなGitインストーラーを使うことで、このGitインストーラーはGoogle Codeのページ（図1-7参照）からダウンロードすることができます：
167 | 
168 | 	http://code.google.com/p/git-osx-installer
169 | 
170 | Insert 18333fig0107.png 
171 | Figure 1-7. Git OS X installer
172 | 
173 | もう一つの主要な方法は、MacPorts (`http://www.macports.org`) からGitをインストールすることです。MacPortsをインストールした状態であれば、Gitを以下のようにインストールできます。
174 | 
175 | 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
176 | 
177 | 全てのvariantsを追加する必要はありませんが、SubversionのリポジトリでGitを使う必要がまだあるなら、恐らく+svnを含めないといけないでしょう（第8章参照）。
178 | 
179 | ### Windowsにインストール ###
180 | 
181 | WindowsにGitをインストールするのはとても簡単です。msysGitプロジェクトは、より簡単なインストール手続きの一つを備えています。Google Codeのページから、単純にインストーラーのexeファイルをダウンロードをし、実行してください：
182 | 
183 | 	http://code.google.com/p/msysgit
184 | 
185 | インストール後、コマンドライン版（後で役に立つSSHクライアントを含む）とスタンダードGUI版の両方を使う事ができます。
186 | 
187 | ## 最初のGitの構成 ##
188 | 
189 | 今や、Gitがシステムにあります。Git環境をカスタマイズするためにしたい事が少しはあることでしょう。アップグレードの度についてまわるので、たった一度でそれらを終わらすべきでしょう。またそれらは、またコマンドを実行することによっていつでも変更することができます。
190 | 
191 | Gitには、git configと呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。これらの変数は三つの異なる場所に格納されうります：
192 | 
193 | *	`/etc/gitconfig` file: システム上の全てのユーザーと全てのリポジトリに対する設定値を保持します。もし`--system`オプションを`git config`に指定すると、明確にこのファイルに読み書きを行ないます。
194 | *	`~/.gitconfig` file: 特定のユーザーに対する設定値を保持します. `--global`オプションを指定することで、Gitに、明確にこのファイルに読み書きを行なわせることができます。
195 | *	現在使っている、あらゆるリポジトリのGitディレクトリの設定ファイル(`.git/config`のことです): 特定の単一リポジトリに対する設定値を保持します。それぞれのレベルの値は以前のレベルの値を上書きするため、`.git/config`の中の設定値は`/etc/gitconfig`の設定値に優先されます。
196 | 
197 | Windows環境下では、Gitは`$HOME`ディレクトリ（ほとんどのユーザーは`C:\Documents and Settings\$USER`)（訳者注：環境変数`USERPROFILE`で指定される）の中の`.gitconfig`ファイルを検索に行きます。また、インストーラー時にWidnowsシステムにGitをインストールすると決めたところにある、MSysのルートとの相対位置であったとしても、/etc/gitconfigも見に行きます。
198 | 
199 | ### 個人の識別情報 ###
200 | 
201 | Gitをインストールしたときに最初にすべきことは、ユーザー名とE-mailアドレスを設定することです。全てのGitのコミットはこの情報を用いるため、これは重要で、次々とまわすコミットに永続的に焼き付けられます：
202 | 
203 | 	$ git config --global user.name "John Doe"
204 | 	$ git config --global user.email johndoe@example.com
205 | 
206 | また、もし`--global`オプションを指定するのであれば、Gitはその後、そのシステム上で行なう（訳者注：あるユーザーの）全ての操作に対して常にこの情報を使うようになるため、この操作を行なう必要はたった一度だけです。もし、違う名前とE-mailアドレスを特定のプロジェクトで上書きしたいのであれば、そのプロジェクトの（訳者注：Gitディレクトリの）中で、`--global`オプション無しでこのコマンドを実行することができます。
207 | 
208 | ### エディター ###
209 | 
210 | 今や、個人の識別情報が設定され、Gitがメッセージのタイプをさせる必要があるときに使う、標準のテキストエディターを設定できます。標準では、Gitはシステムのデフォルト・エディターを使います。これは大抵の場合、ViかVimです。Emacsのような違うテキスト・エディターを使いたい場合は、次のようにします：
211 | 
212 | 	$ git config --global core.editor emacs
213 | 	
214 | ### diffツール ###
215 | 
216 | 設定したいと思われる、その他の便利なオプションは、マージ（訳者注：複数のリポジトリを併合すること）時の衝突を解決するために使う、標準のdiffツールです。vimdiffを使いたいとします：
217 | 
218 | 	$ git config --global merge.tool vimdiff
219 | 
220 | Gitはkdiff3、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff、ecmerge、opendiffを確かなマージ・ツールとして扱えます。カスタム・ツールもまた設定できますが、これをする事に関しての詳細な情報は第7章を参照してください。
221 | 
222 | ### 設定の確認 ###
223 | 
224 | 設定を確認したい場合は、その時点でGitが見つけられる全ての設定を一覧するコマンドである`git config --list`を使う事ができます：
225 | 
226 | 	$ git config --list
227 | 	user.name=Scott Chacon
228 | 	user.email=schacon@gmail.com
229 | 	color.status=auto
230 | 	color.branch=auto
231 | 	color.interactive=auto
232 | 	color.diff=auto
233 | 	...
234 | 
235 | Gitは異なったファイル(例えば`/etc/gitconfig`と`~/.gitconfig`)から同一のキーを読み込むため、同一のキーを1度以上見ることになるでしょう。この場合、Gitは見つけたそれぞれ同一のキーに対して最後の値を用います。
236 | 
237 | また、Gitに設定されている特定のキーの値を、`git config {key}`をタイプすることで確認することができます：
238 | 
239 | 	$ git config user.name
240 | 	Scott Chacon
241 | 
242 | ## ヘルプを見る ##
243 | 
244 | もし、Gitを使っている間は助けがいつも必要なら、あらゆるGitコマンドのヘルプのマニュアル・ページ（manpage）を参照する3種類の方法があります。
245 | 
246 | 	$ git help 
247 | 	$ git  --help
248 | 	$ man git-
249 | 
250 | 例えば、configコマンドのヘルプのmanpageを次のコマンドを走らせることで見ることができます。
251 | 
252 | 	$ git help config
253 | 
254 | これらのコマンドは、オフラインのときでさえ、どこでも見る事ができるので、すばらしいです。
255 | もしmanpageとこの本が十分でなく、人の助けが必要であれば、フリーノードIRCサーバー（irc.freenode.net）の`#git`もしくは`#github`チャンネルにアクセスしてみてください。これらのチャンネルはいつも、全員がGitに関してとても知識があり、よく助けてくれようとする数百人の人々でいっぱいです。
256 | 
257 | ## まとめ ##
258 | 
259 | Gitとは何か、どのように今まで使われてきた他のCVCSと異なるのかについて、基本的な理解ができたはずです。また、今や個人情報の設定ができた、システムに稼動するバージョンのGitがあるはずです。今や、本格的にGitの基本を学習するときです。
260 | 


--------------------------------------------------------------------------------
/ja/README:
--------------------------------------------------------------------------------
 1 | 書籍「Pro Git」のコンテンツ
 2 | ===========================
 3 | 
 4 | (トップディレクトリにあるREADMEの日本語訳です)
 5 | 
 6 | これは、書籍「Pro Git」のコンテンツのソースコードです。
 7 | Creative Commons Attribution-Non Commercial-Share Alike 3.0 license のもとで公開しています。
 8 | お楽しみください。本書が Git を学ぶ手助けとなることを期待します。また、
 9 | Apress や私を支援してくださる意味でも、ぜひ書籍版を Amazon からご購入ください。
10 | 
11 | http://tinyurl.com/amazonprogit
12 | 
13 | 訳注: 上のtinyurlは、amazon.comのアフィリエイトIDつきのURLにリダイレクトされます。
14 | 
15 | 
16 | Ebookのつくりかた
17 | =====================
18 | 
19 | Fedora なら、たとえばこのようにします。
20 | 
21 |     $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug 
22 |     $ gem install rdiscount
23 |     $ makeebooks en  # これで mobi ファイルができあがります
24 | 
25 | 不具合
26 | =====================
27 | 技術的な間違いやその他の修正を要する点を発見した場合は、schacon at gmail dot com
28 | へのメールで私 (Scott Chacon) に教えてください。
29 | 
30 | 訳注: 当然、Scott へのメールは英語で書いてください :-) 日本語訳に関する指摘は、
31 | 日本語版の翻訳に参加しているメンバーの誰かにメッセージを送っていただけるとありがたいです。
32 | 
33 | 
34 | 翻訳
35 | =====================
36 | この本を翻訳してくだされば、その翻訳を progit.org のサイトで公開させていただきます。
37 | このプロジェクトの適切なディレクトリ (たとえばイタリア語なら 'it' など) に翻訳を置き、
38 | 私 (schacon) に pull request を送ってください。
39 | 


--------------------------------------------------------------------------------
/ja/translation glossaries.txt:
--------------------------------------------------------------------------------
 1 | # UTF-8でっせ
 2 | (vt)store	格納
 3 | (n)change	変更
 4 | (n)modify	修正
 5 | (vt)stage	ステージする
 6 | (n)staging area	ステージング・エリア
 7 | (n)GIT directory	Gitディレクトリ
 8 | (n)working directory	作業ディレクトリ
 9 | (n)workflow	ワークフロー
10 | (a)comitted	コミット済
11 | (a)modified	修正済
12 | (a)staged	ステージ済
13 | (n)non-linear development	ノンリニア開発
14 | (n)chapter	章
15 | # カタカナ用語末尾の長音関連
16 | # 参考: マイクロソフト日本語スタイルガイド
17 | # http://www.microsoft.com/language/ja/jp/download.mspx
18 | # http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3491
19 | (n)browser	ブラウザー
20 | (n)computer	コンピューター
21 | (n)community	コミュニティ
22 | (n)data	データ
23 | (n)database	データベース
24 | (n)designer	デザイナー
25 | (n)directory	ディレクトリ
26 | (n)installer	インストーラー
27 | (n)interface	インターフェイス
28 | (n)member	メンバー
29 | (n)nonlinear	ノンリニア
30 | (n)programmer	プログラマ
31 | (n)repository	リポジトリ
32 | (n)server	サーバー
33 | (n)user	ユーザー
34 | 


--------------------------------------------------------------------------------
/ko/01-introduction/01-chapter1.markdown:
--------------------------------------------------------------------------------
  1 | # 시작하기 #
  2 | 
  3 | 이 장에서는 힘내와 함께 시작에 관한 것입니다. 우리는 버전 제어 도구에 대한 몇 가지 배경 설명에 의해 처음에 다음이 시작됩니다 힘내 어떻게 귀하의 시스템에서 실행 마지막으로 어떻게 설치 작업을 시작 들어가야에 이동합니다. 왜 망할놈의 주위에, 왜 당신이 그것을 사용해야 이해해야한다이 장의 끝에 당신의 모든 설정을 그렇게되어야합니다.
  4 | 
  5 | ## 버전 제어 란 ##
  6 | 
  7 | 어떤 버전 제어, 그리고 왜 상관해야 하나요? 버전 관리 시스템입니다 파일에 레코드를 변경하거나 파일의 시간이 너무 이상하면 나중에 특정 버전의 설정 리콜 수있습니다. 당신 파일을 받고 버전 제어 소프트웨어의 소스 코드를 사용하여이 책에 예제, 비록 현실에 대한 당신의 컴퓨터에있는 파일의 거의 모든 유형이 할 수있습니다.
  8 | 
  9 | 경우 또는 웹 디자이너 및 그래픽 이미지 또는 레이아웃의 모든 버전을 계속하고 싶어합니다 (이는 가장 확실하게하려면), 버전 제어 시스템 (VCS는)를 사용하여 아주 현명한 일이 원하는 것이다. 그것은 다시 이전의 상태로 되돌리려면 파일을 다시 이전 상태로 되돌리려면 전체 프로젝트, 시간이 지남에 변경 사항을, 마지막으로 바뀌었습니다 누가 뭔가가 문제의 원인이 될 수도 비교해 볼 수 있도록, 누가 문제와 때, 그리고 더 많은 도입했다. VCS는 사용하는 경우도 일반적으로 당신이 일을 망치거나 파일이 손실은, 당신은 쉽게 복구할 수있습니다. 또한, 당신은 매우 작은 오버헤드가 모든이에게 갖다.
 10 | 
 11 | ### 로컬 버전 제어 시스템 ###
 12 | 
 13 | 많은 사람들이 선택의 여지는 버전 제어 방식을 다른 디렉토리에 (아마도 시간이 찍혀 디렉토리에 그들이 똑똑한 경우) 파일을 복사하는 것입니다. 이유는 너무 간단하다 이러한 접근 방식은 매우 일반적이지만, 그것도 엄청난 오류가 발생하기 쉬운입니다. 그것은 당신과 우연히이야 잘못된 파일 또는 복사에 쓸 디렉토리를 잊기 쉬운 파일, 당신에게 말은하지 않습니다.
 14 | 
 15 | 이 문제를 해결하려면, 프로그래머는 오래 전 (그림 1-1 참조) 그 개정을 통제 아래에있는 파일에 대한 모든 변경 사항을 계속 간단한 데이터베이스를 가지고 지역 VCSs 개발했다.
 16 | 
 17 | Insert 18333fig0101.png
 18 | 그림 1-1. 로컬 버전 제어 다이어그램.
 19 | 
 20 | 하나는 더 많은 인기를 VCS는 도구는 여전히 많은 컴퓨터에 분산되어 오늘날 시스템 RCS라는 기록했다. 심지어 인기있는 맥 OS X 운영 체제를하면 개발자 도구를 설치 RCS 명령을 포함합니다. 이 도구는 기본적으로 패치 세트를 유지하는 작품 (즉, 디스크에 특별한 형식이 다른 하나의 변화에서 파일 사이의 차이점); 말하면 그 다음에 다시하실 수있습니다 언제 어느 시점에서처럼 추가하여 파일을 만들려면 어떻게 생겼는지를 모두 패치.
 21 | 
 22 | ### 중앙 집중식 버전 제어 시스템 ###
 23 | 
 24 | 다음의 주요 문제는 사람들이 그들이 발생하는 다른 시스템에서 개발자와 협력이 필요합니다. 이 문제를 처리하기 위해, 중앙 집중식 버전 제어 시스템 (CVCSs)을 개발했다. CVS는, Subversion은 등과 같은 이러한 시스템, 그리고 퍼포, 그리고 고객의 숫자가 모든 버전의 파일이 들어있는 단일 서버가 그 중앙 장소에서 파일을 체크 아웃. 수년 동안,이 (그림 1-2 참조) 버전 제어를위한 표준되었습니다.
 25 | 
 26 | Insert 18333fig0102.png
 27 | 그림 1-2. 중앙 버전 제어 다이어그램.
 28 | 
 29 | 이 설정을 로컬 VCSs, 특히 많은 이점을 제공한다. 예를 들어, 모든 프로젝트에 다른 사람들은 뭐하고있다가 어느 정도 알고 있죠. 누가 무엇을, 그리고 그것보다 훨씬 그것을 모든 클라이언트에 로컬 데이터베이스와 거래를하는 것입니다 CVCS 관리를 쉽게 할 수있는 이상의 관리자가 세부적으로 제어할 수있습니다.
 30 | 
 31 | 그러나,이 설정도 몇 가지 심각한 단점이있다. 가장 명백한 실패의 중앙 서버를 나타내는 단일 지점입니다. 만약 서버가 1 시간 동안 아무도 그 시간 모두에서 협업할 수 또는 그들이 최선을 다하고있습니다 뭐든 버전의 변경 내용을 저장하는 동안갑니다. 만약 중앙 데이터베이스가 손상된 경우에 하드 디스크, 그리고 적절한 백업을 보관하지 않은, 당신은 절대적으로 모든 것을 원하는 사람들을 제외하고 하나의 스냅샷이 프로젝트의 전체 역사를 잃고 자신의 로컬 컴퓨터에서이 일어날. 지역 VCS는 시스템이 동일한 문제를 겪고 때마다 당신이 한 장소에서 프로젝트의 전체 역사를 가지고, 당신은 모든 걸 잃을 위험.
 32 | 
 33 | ### 버전 제어 시스템 분산 ###
 34 | 
 35 | 여기서 버전 컨트롤 시스템 (DVCSs) DVCS 단계에서 안으로 힘내, 의욕, 바자 또는 Darcs (예)로, 고객이 단지 파일의 최신 스냅샷을 선택하지 마십시오 : 그들은 완전히 거울을 분산 저장소입니다. 따라서 서버에있는 경우, 그리고 죽으면 이러한 시스템을 그것을 통해 모든 클라이언트가 저장소의 백업 서버로 복원하는 방법을 복사할 수있습니다 협업했다. 모든 결제 정말 모든 데이터의 전체 백업 (그림 1-3 참조)입니다.
 36 | 
 37 | Insert 18333fig0103.png
 38 | 그림 1-3. 분산 버전 관리 다이어그램.
 39 | 
 40 | 또한, 이러한 시스템의 많은 꽤 잘 그들이 작업을 수있는 몇 가지 원격 저장소를 갖는, 그래서 다른 방법으로 사람들이 다른 그룹과 같은 프로젝트 내에서 동시에 협업할 수있는 거래. 이것은 당신이 계층 모델과 같은 중앙 집중화된 시스템에서 가능하지 않습니다 워크플로우의 여러 유형을 설정할 수있습니다.
 41 | 
 42 | ## 망할놈의 짧은 역사 ##
 43 | 
 44 | 인생에서 많은 좋은 것들과 마찬가지로, 망할놈의 창조적 파괴와 불타는 논쟁의 비트와 함께 시작했다. 리눅스 커널은 상당히 큰 범위의 오픈 소스 소프트웨어 프로젝트입니다. 리눅스 커널의 유지 보수 (1991에서 2002 사이), 소프트웨어에 대한 변경 사항의 일생의 대부분을위한 패치 및 보관된 파일을 주변에 전달했다. 2002 년, 리눅스 커널 프로젝트는 독자적인 시스템이라는 DVCS 비트 키퍼를 사용하기 시작했다.
 45 | 
 46 | 2005 년, 리눅스 커널을 개발하고 비트 키퍼가 고장이 회사가 개발한 상용 사회 사이의 관계, 그리고 자유의 도구의 충전 상태를 취소했다. 이것은 (특히 리누스 토발즈, 리눅스의 창시자)에 자신의 도구를 개발하는 몇 가지 비트 키퍼를 사용하는 동안 그들이 배운 교훈을 바탕으로 리눅스 개발 커뮤니티하라는 메시지가 나타나면. 일부는 새로운 시스템의 목표였다는 다음과 같습니다 :
 47 | 
 48 | * 속도
 49 | * 심플한 디자인
 50 | * 이외의 강력한 지원 선형 개발을 병렬로 지점 (수천)
 51 | * 완전 분산
 52 | * 에이블 리눅스 커널과 같은 대형 프로젝트를 효율적으로 처리 (속도와 데이터 크기)
 53 | 
 54 | 2005 년 탄생 이래, 망할놈의 발전 및 성숙 쉽게 사용할 수와 아직은 이러한 초기 자질을 보유합니다. 그것은 매우 빨리, 아주 큰 프로젝트를 효율적이고, 그 이외의 놀라운 분기 시스템 선형 개발하고있다 () 제 3 장 참조하십시오.
 55 | 
 56 | ## 망할놈의 기본 ##
 57 | 
 58 | 그래서, 무슨 말도 안되는 소리 같지만 힘내 무엇입니까? 만약 당신이 어떤 망할놈의 작동 방법의 기초, 그리고 효과적으로 아마 훨씬 쉬울 것입니다 힘내 사용하는 이해이 흡수하는 중요한 부분이다 당신을 위해. 보시다시피, 망할놈의 내용은 당신이 서브와 퍼포 같은 다른 VCSs에 대해 알고있을 것을 당신의 마음을 비우려고; 일을 이렇게하면 도구를 사용하여 섬세하고 혼동을 피하기 위해 도움이됩니다. 그것을 사용하는 동안 힘내 매장과 생각에 대한 정보를 많이 다르게 이러한 다른 시스템에 비해, 비록 사용자 인터페이스가 매우 유사합니다; 그 차이를 이해 해지고 혼란스러워하지 못하도록 도움이됩니다.
 59 | 
 60 | ### 스냅샷, 아니 차이점 ###
 61 | 
 62 | 힘내 및 기타 VCS는 사이에 큰 차이 (Subversion을 친구 포함) 방식으로 힘내이며 데이터에 대해 생각한다. 개념, 파일의 변경 사항 목록을 기반으로 대부분의 다른 시스템 정보를 저장합니다. 이러한 시스템 (CVS는, Subversion을, 퍼포, 바자 등) 그들은 파일의 설정 및 변경 시간이 지남에 따라 각 파일에 만들어진만큼 그림 1-4에서 그림과 같이 계속 정보를 같아요.
 63 | 
 64 | Insert 18333fig0104.png
 65 | 그림 1-4. 다른 시스템의 각 파일의 기본 버전을 변경 데이터를 저장하는 경향이있다.
 66 | 
 67 | 힘내 생각하지 않습니다 이런식으로 데이터를 저장할 수있습니다. 대신, 힘내 자사의 데이터를 미니 파일 시스템의 스냅샷을 설정처럼 생각한다. 매번 당신은, 커밋 또는 힘내에서 귀하의 프로젝트의 상태를 저장하면 기본적으로 모든 파일을 그 순간에 매장이 스냅샷에 대한 참조를 어떻게 생겼는지 사진 걸립니다. 효율적으로, 만약 파일이 변경되지 않은, 힘내 파일을 다시 저장하지 않습니다 단지 링크가 이미 저장된 파일은 이전과 동일. 힘내 그림 1-5처럼 데이터에 대해 생각한다.
 68 | 
 69 | Insert 18333fig0105.png
 70 | 그림 1-5. 시간의 경과에 프로젝트의 스냅샷으로 망할놈의 데이터를 저장합니다.
 71 | 
 72 | 이 망할놈의 거의 모든 다른 VCSs 사이에 중요한 차이가있습니다. 그 망할놈의 대부분의 다른 시스템에 이전 세대에서 복사한 버전 제어의 거의 모든 측면을 재고해 수있습니다. 이것은 약간의 대단히 강력한 도구를 꼭대기에 지어진 것이 아니라 단순히 VCS는 함께 미니 파일 시스템을 더 힘내 수있습니다. 귀하의 데이터를 이런식으로 우리가 제 3 분기 망할놈의 덮개를 생각하여 이득의 일부 혜택을 탐험합니다.
 73 | 
 74 | ### 거의 모든 작업 로컬 ###
 75 | 
 76 | 힘내에서 대부분의 작업에만 작동하도록 - 일반적으로 어떠한 정보도 네트워크상의 다른 컴퓨터에서 필요한 로컬 파일과 리소스를 필요합니다. 만약 당신이 CVCS를 사용하는지, 어디에 대부분의 작업, 망할놈의 관점에서 그 속도의 신들이 속세를 떠난 능력이 망할놈의 축복을 생각하게됩니다 네트워크 지연 오버헤드가있다. 왜냐하면 당신이 로컬 디스크에있는 프로젝트는 바로 거기의 전체 역사를 가지고 대부분의 작업을 거의 즉각 보인다.
 77 | 
 78 | 예를 들어, 힘내 서버로 가서 역사를 그리고 당신을위한 표시가 필요하지 않습니다 그것은 단순한 직접 로컬 데이터베이스에서 읽습 프로젝트의 역사를 탐색할 수있습니다. 이렇게하면 거의 즉시 프로젝트 역사를 볼 것을 의미합니다. 만약 변경 사항을 파일의 현재 버전 개월 전 파일 사이의 도입을보고 싶어, 힘내 개월 전 파일을 로컬 차이를 계산을 할 대신하거나 원격 서버에 요청하는 데 그것을 어떻게 찾아볼 수있습니다 또는 로컬로 그것을 할 원격 서버에서 파일의 이전 버전을 당겨.
 79 | 
 80 | 이것은 또한 당신이 오프라인을 켜거나 VPN에 매우 당신이 할 수 없어 조금 남아있는 것을 의미합니다. 만약 당신이 비행 기나 기차를 타고 가서 일을 좀하려면, 당신이 행복까지 업로드 네트워크 연결에 도착 커밋 수있습니다. 만약 당신이 집에 가서 귀하의 VPN 클라이언트가 올바르게 작동 얻을 수 없다, 당신은 여전히 사용할 수있습니다. 많은 다른 시스템에서는, 이렇게하면 하나 또는 고통스러운 것은 불가능하다. 퍼포스 있음, 예를 들면, 당신은 당신이 서버에 연결되지 않은 할 수 없어, 그리고 CVS에서 Subversion을 그리고, 당신이 파일을 편집할 수 있지만 귀하의 데이터베이스 (되었기 때문에 데이터베이스)가 오프라인 상태 변경 내용을 커밋 수없습니다 . 이것은 큰 거래를 보이되지 않을 수도있습니다,하지만 당신은 그것을 큰 차이가 무엇을 할 수 놀랄 수있습니다.
 81 | 
 82 | ### 망할놈의 무결성가 ###
 83 | 
 84 | 힘내에서 모든 체크하기 전에 그것 저장되어 다음에 그 체크섬에 의해 참조된입니다 요약될. 이렇게 힘내하지 않고 그것에 대해 아는 모든 파일이나 디렉토리의 내용을 변경 불가능을 의미합니다. 이 기능은 GIT에 최저 수준에와 철학에 필수적인 부분입니다 내장되어있습니다. 당신은 교통 정보를 잃을 수 없거나 힘내 그것을 감지할 수없이 손상이 파일을 가져올.
 85 | 
 86 | 망할놈의 메커니즘이 checksumming에 대한은 SHA - 1 해시 전화를 사용합니다. 이것은 40 - 문자 문자열을 16 진수 문자 (0-9 및 구성되어 - f 옵션) 및 힘내에서 파일이나 디렉토리 구조의 내용을 기반으로 계산됩니다. 은 SHA - 1 해시는 다음과 같이 보입니다 :
 87 | 
 88 | 24b9da6552252987aa493b52f8696cd6d3b00373
 89 | 
 90 | 너 때문에 너무 많이 사용 그들이 해시는 망할놈의 여기저기 값을 볼 수있습니다. 사실, 파일 이름을하지 않음으로써 힘내 상점 빼고는 다 망할놈의 데이터베이스에있는 내용의 해시 값에 의해 처리할 수.
 91 | 
 92 | ### 힘내 일반적으로 데이터만 추가 ###
 93 | 
 94 | 하면, 힘내에서 작업을 할 거의 모든 그들의 유일한 망할놈의 데이터베이스에 데이터를 추가할 수있습니다. 그것은 매우 취소할 수 없거나 어떤 방식으로 데이터를 지울 수 있도록 아무것도 할 시스템 어렵습니다. 모든 VCS는 마찬가지로, 당신은 잃을 수있다 또는 당신이 아직 커밋되지 않은 변경 사항을 엉망으로,하지만 후에 GIT에 스냅샷을 커밋, 그것은 매우 어렵습니다 잃고, 특히 만일 당신이 정기적으로 다른 저장소 데이터베이스를 밀어.
 95 | 
 96 | 우리가 심각하게 일을 망쳐의 위험없이 할 수있는 실험을 아는 기쁨이 망할놈를 사용합니다. 힘내 저장하는 방법에 자사의 데이터를 심도 좀 더 당신이 어떻게 볼 것 잃어버린 데이터를 복구할 수있다 "덮어 아래에서"제 9있습니다.
 97 | 
 98 | ### 3 미국 ###
 99 | 
100 | 자, 주목을 지불해야합니다. 이렇게하면 원활하게 이동하여 학습 과정의 나머지 원하는 힘내 대한 기억 중요한 건입니다. 망할놈의 세 가지 기본 상태는 귀하의 파일에 거주하고있습니다 :이,, 수정 및 개최 헌신. 최선을 다하고 뜻을 안전하게 데이터를 로컬 데이터베이스에 저장됩니다. 수정된 것을 의미하지만 그 파일을 변경하여 데이터베이스에 아직 커밋되지 않은있습니다. 즉, 당신이 옆에있는 스냅샷을 커밋에 들어가 현재 버전에서 수정된 파일을 표시한 연출한.
101 | 
102 | 이 망할놈의 프로젝트의 세 가지 주요 섹션에 우리가 리드 : 망할놈의 디렉토리, 작업 디렉토리, 그리고 준비 영역입니다.
103 | 
104 | Insert 18333fig0106.png
105 | 그림 1-6. 작업 디렉토리, 지역의 준비, 그리고 자식 디렉터리에있습니다.
106 | 
107 | 힘내 힘내 디렉토리는 어디에 저장하여 프로젝트에 대한 메타 데이터 및 개체를 데이터베이스. 이 망할놈의 가장 중요한 부분이며, 무엇을하면 다른 컴퓨터에서 저장소를 복제 복사입니다.
108 | 
109 | 작업 디렉토리 프로젝트의 버전 중 하나 하나 체크 아웃됩니다. 이러한 파일은 망할놈의 디렉토리에 압축 데이터베이스의 철수하고 당신을 사용하거나 수정하여 디스크에 배치.
110 | 
111 | 준비 영역에 파일을 간단하고, 일반적으로 여러분 힘내 디렉토리에, 그게 다음 커밋에 들어갈 예정에 대해 정보 저장소에 포함되어있습니다. 그것은 때때로 지수라고도했지만, 그것을 위해 표준을 준비 영역으로 참조되고 있어요.
112 | 
113 | 기본 힘내 워크플로우 이런 식입니다 :
114 | 
115 | 1. 귀하의 작업 디렉토리에있는 파일을 수정할 수있습니다.
116 | 2. 당신은 당신의 준비 영역에 그들의 스냅샷 파일을 추가 단계입니다.
117 | 3. 당신, 이는 그들이 준비 지역 상점에있는 파일을 커밋 할 필요가 스냅샷을 여러분 힘내 디렉터리를 영구적으로합니다.
118 | 
119 | 만약 파일의 특정 버전의 자식 디렉터리에있는 경우, 그것을 최선을 다하고 고려됩니다. 하지만, 만약 수정이 준비 영역에 추가되었습니다, 그것을 개최합니다. 그리고 이후지만, 체크 아웃 개최되지 않은 경우가 변경되었습니다, 그것을 수정합니다. 제 2 장, 당신은 이러한 상태에 대해 자세히 살펴보겠습니다 방법 중 하나를 그들을 활용할 수 있으며 완전히 연출된 부분을 건너 뛰십시오.
120 | 
121 | ### 설치 힘내 ###
122 | 
123 | 좀 힘내을 사용하여 들어가 보자. 중요한 것부터 먼저 - 당신이 그것을 설치해야합니다. 당신은 여러 가지 방법으로 얻을 수 있으며 두 가지 중요한 것들 원본하거나 설치하는 데 필요한 플랫폼을위한 기존의 패키지를 설치하고있습니다.
124 | 
125 | ### 설치 소스에서 ###
126 | 
127 | 만약 당신이 할 수 있기 때문에 당신이 가장 최근 버전을받을거야, 일반적으로 원본 망할놈의 설치에 유용합니다. 망할놈의 각 버전에 유용한 UI가 개선을 포함, 그래서 최신 버전을 받고 경향이 종종 느낀다면, 네가 소스로부터 소프트웨어를 컴파일하고 편안하게 최상의 경로입니다. 또한 많은 리눅스 배포판은 아주 오래된 패키지를 포함하는 경우; 그렇게하지 않으면 매우 올라있어 - 최고의 내기있을 수있습니다 - 최신 배포판 또는 백포트를 사용하는 경우 소스에서 다시 설치하십시오.
128 | 
129 | 힘내 설치하려면, 당신은 그 망할놈에 따라 다음과 같은 라이브러리 :,,, expat하려면 openssl zlib을 곱슬 곱슬하게 가지고, 필요 libiconv. 예를 들어, 만약 당신이 시스템에 냠 페도라 (예) 또는 apt - get을 가지고있어 (데비안 기반의 시스템과 같은), 당신의 모든 종속성을 설치하려면 다음 명령 중 하나를 사용할 수있습니다 :
130 | 
131 | $ 냠 곱슬 곱슬 - devel expat - devel로 gettext - devel \ 설치
132 | zlib을하려면 openssl - devel - devel
133 | 
134 | $는 apt - dev에 gettext를 \ - gnutls - dev에 설치 얻을 libexpat1 libcurl4
135 | libz - dev에
136 | 
137 | 때 필요한 모든 종속성을 가지고 가서 수 망할놈의 웹 사이트에서 최신 스냅샷을 잡으 :
138 | 
139 | http://git-scm.com/download
140 | 
141 | 그럼, 컴파일 및 설치 :
142 | 
143 | $ 타르 - zxf 이눔아 - 1.6.0.5.tar.gz
144 | $ CD를 이눔아 - 1.6.0.5
145 | $ 접두어 =는 / usr / 모든 지역을
146 | $ sudo를 =는 / usr / 설치 로컬 접두사를 확인
147 | 
148 | 후에이 완료되면, 당신도 힘내 자체를 통해 업데이 트에 대한 힘내 얻을 수있습니다 :
149 | 
150 | $ 이눔아 이눔아 클론 : / / git.kernel.org / 펍 / SCM에서 / 자식 / git.git
151 | 
152 | ### 설치 Linux에서 ###
153 | 
154 | 만약 당신이 리눅스에서 바이너리 설치를 통해 힘내 설치하려면, 일반적으로 너무 기본적인 패키지를 통해 할 수있는 관리 도구는 귀하의 배포와 함께 제공됩니다. 만약 당신이 페도 라에있는거야, 당신은 냠 사용할 수있습니다 :
155 | 
156 | $ 냠 자식을 설치 코어
157 | 
158 | 아니면 당신이 데비안에 있어요 - 우분투 같은 배포판을 기반으로, 시도는 apt - get은 :
159 | 
160 | $는 apt - 이눔아 설치 얻을 코어
161 | 
162 | ### 설치 Mac에서 ###
163 | 
164 | 저기 힘내 Mac에서 설치하는 두 가지 간단한 방법입니다. 가장 쉬운 방법 (그림 1-7 참조) : 당신이 구글 코드 페이지로부터 다운로드할 수있습니다 그래픽 망할놈의 설치, 사용하는 것입니다
165 | 
166 | http://code.google.com/p/git-osx-installer
167 | 
168 | Insert 18333fig0107.png
169 | 그림 1-7. 힘내 OS X의 설치.
170 | 
171 | 다른 주요 방법을 통해 힘내 MacPorts를 설치하는 것입니다 (``) http://www.macports.org. 만약 당신이 망할놈의 설치를 통해 MacPorts 설치
172 | 
173 | $ sudo를 포트에 자식을 설치 코어 + svn + 의사 + bash_completion + gitweb
174 | 
175 | 모든 엑스트라를 추가할 필요는 없지만, 아마 당신을 포함하기를 원할거야 + svn 경우 혹시 Subversion은 저장소와 (제 8 장 참조) 힘내 사용해야합니다.
176 | 
177 | ### 설치 윈도우에서 ###
178 | 
179 | 힘내 Windows에서 설치 매우 간단합니다. msysGit 프로젝트는 하나 쉽게 설치 절차했다. 간단히 말하면, 구글 코드 페이지에서 설치 프로그램을 exe 파일을 다운로드하고 실행합니다 :
180 | 
181 | http://code.google.com/p/msysgit
182 | 
183 | 후에 설치되어있는 경우 (즉, 들어올 것입니다 SSH 클라이언트를 포함하여 모두 명령줄 버전 이상) 및 표준 GUI를 편리.
184 | 
185 | ### 처음 힘내 설치 ###
186 | 
187 | 이제 여러분의 시스템에 힘내 가지고 여러분 힘내 환경을 사용자 정의하는 몇 가지 일을하고 싶어합니다. 너 한번만 이런 일을해야한다; 그들은 업그레이 드를 사이에 제 곁에 계셔야합니다. 또한 명령을 다시 실행하여 언제든지 변경할 수있습니다.
188 | 
189 | 망할놈의 도구를 함께 데려 및 구성 변수를 설정할 수있습니다 전화 오면 자식 구성하는 방법을 망할놈의 외모와 운영의 모든 측면을 통제. 이러한 변수는 세 가지 다른 위치에 저장되어있을 수있습니다 :
190 | 
191 | *`은 / etc /`파일을 gitconfig : 시스템에있는 모든 사용자와 모든 리포지 토리에 대한 값이 포함되어있습니다. 만일 당신이 옵션`을 통과 - 시스템`에`config를 자식, 그것을 읽고 해당 파일을 구체적으로부터 씁니다.
192 | *`~ /.`파일을 gitconfig : 사용자에게 특정. 넌 망할놈의 읽기 및이 파일에 특별히`-`글로벌 옵션을 전달하여 작성 할 수있습니다.
193 | 자식 디렉터리에 * config 파일 (즉 .git,`은 /`설정) 현재 사용하고 계시는 어떤 저장소의 종류 : 단일 저장소에 특정. 각 단계는 이전 단계에있어서`.git 값을 값을 무시 /`트럼프의 이러한 설정은 / etc / gitconfig`.
194 | 
195 | Windows 시스템에서, 힘내````$ 홈 디렉토리에 (`에 C : \ 문서 및 설정 \ $ 사용자`대부분의 사람들에게) 파일 gitconfig. 찾습니다. 비록 그것이 어디에 있든 당신이 Windows 시스템에 설치하면 실행 망할놈의 설치를 결정합니다 MSys 루트, 상대의 그것은 여전히 / 용 등 / gitconfig 보인다.
196 | 
197 | ### 귀하의 신원을 ###
198 | 
199 | 힘내하면 설치해야합니까 우선 사용자 이름과 전자 메일 주소를 설정하는 것입니다. 왜냐하면 모든 힘내 커밋이 중요한이 정보를 사용합니다, 그리고 그것을 immutably 당신 주위에 패스를 저지른에 덜떨어진 :
200 | 
201 | $ 자식 설정 - 글로벌 user.name "John Doe의"
202 | $ 자식 설정 - 글로벌 user.email johndoe@example.com
203 | 
204 | 다시 말하지만, 당신이 한 번만 그 때문에 항상 힘내 시스템에서하는 일은 그 정보를 사용할 것입니다 만약 당신이`-`글로벌 옵션을 통과 이렇게해야합니다. 만약 당신이 다른 이름 또는 특정 프로젝트에 대한 전자 메일 주소와 함께이 오버 라이드하고 싶다면, 당신은`-`글로벌 옵션을 선택하지 않고 당신이 그 프로젝트에있어 명령을 실행할 수있습니다.
205 | 
206 | ### 당신의 에디터 ###
207 | 
208 | 이제 귀하의 신원을 구성할 수있습니다 힘내 입력하면 메시지에 당신을 필요로하는 데 사용됩니다 기본 텍스트 편집기 설정됩니다. 기본적으로, 힘내 일반적으로 귀하의 시스템의 기본 편집기를 사용 바이올렛 또는 Vim은. 만약 당신이 emacs와 같은 다른 텍스트 편집기를 사용하려면 다음 작업을 수행할 수있습니다 :
209 | 
210 | $ 자식 설정 - 글로벌 core.editor 이맥스
211 | 
212 | ### 당신 Diff 도구 ###
213 | 
214 | 당신을 구성할 수있습니다 또 다른 유용한 옵션이 충돌 병합을 해결하는 데 사용하는 기본은 diff 도구입니다. 당신 vimdiff 사용하고자하는 말 :
215 | 
216 | $ 자식 설정 - 글로벌 merge.tool vimdiff
217 | 
218 | 힘내, kdiff3, tkdiff, xxdiff, vimdiff, gvimdiff, ecmerge 등장할 융합 수용 및 병합 도구를 유효로 opendiff. 당신은 또한 사용자 정의 도구를 설정할 수있습니다; 뭐하는 대한 자세한 내용은 제 7 장 보입니다.
219 | 
220 | ### 귀하의 설정 확인 ###
221 | 
222 | 만약 당신이 설정을 확인하려면, 당신이 망할놈의 그 지점에서 찾을 수있는 모든 환경 설정 목록에`명령`자식 설정 - 목록을 사용할 수있습니다 :
223 | 
224 | $ 자식 설정 - 목록
225 | user.name = 스콧 Chacon
226 | user.email = schacon@gmail.com
227 | color.status = 자동
228 | color.branch = 자동
229 | color.interactive = 자동
230 | color.diff = 자동
231 | ...
232 | 
233 | 힘내 있기 때문에 다른 파일에서 읽습니다 키와 동일한 키를 두 번 이상 (`은 / etc / gitconfig`와`~ /.`gitconfig 볼 수있습니다, 예를 들면). 이 경우, 각각의 고유한 망할놈의 열쇠를보고 그것에 대한 마지막 값을 사용합니다.
234 | 
235 | 또한, 망할놈의 특정 키 값을 ()`열쇠`config를 입력하여 자식이 무슨 생각을 확인할 수있습니다 :
236 | 
237 | $ 이눔아 설정 user.name
238 | 스콧 Chacon
239 | 
240 | ### 도움말 얻기 ###
241 | 
242 | 힘내 사용하는 동안 있으면 도움이 절대 필요, 거기 매뉴얼 페이지 () 어떤 망할놈의 명령에 대한 도움을 맨페이지 : 얻을 세 가지 방법이있습니다
243 | 
244 | $ 이눔아 도움이 
245 | $  이눔아 - 도움말
246 | $ 남자 이눔아 - 
247 | 
248 | 예를 들어, 실행하여 설정 명령에 대한 맨페 도움을받을 수
249 | 
250 | $ 이눔아 도움이 구성
251 | 
252 | 당신이 아무데도 오프라인에서 액세스할 수있는 이러한 명령은 잘됩니다.
253 | 만약 man 페이지이 책은 충분하지하고 필요하면 freenode IRC 서버 (irc.freenode.net)에`# 자식`이나`# github`채널을 시도할 수있습니다 - 사람 도움이있습니다. 이러한 채널을 정기적으로 사람 모두 힘내 대해 자주 도움을하고자하는 지식입니다 수백명의 사람들이 가득합니다.
254 | 
255 | ## 요약 ##
256 | 
257 | 당신은 어떻게 당신이 사용되었을 수도있습니다 CVCS 다른 무엇이 망할놈의 기본적인 이해해야합니다. 당신은 또한 현재 여러분의 시스템에 대한 사용자의 개인 신원을 함께 설정이 망할놈의 작업 버전이 있어야합니다. 지금은 어떤 망할놈의 기초를 배울 시간이야.
258 | 


--------------------------------------------------------------------------------
/latex/README:
--------------------------------------------------------------------------------
 1 | PDF Version of Pro Git
 2 | ======================
 3 | 
 4 | To get a PDF version of Pro Git in English, run `makepdf en` and a file called
 5 | `progit.en.pdf` will appear in the root of the project. `makepdf` required
 6 | pandoc and XeTeX as dependencies.
 7 | 
 8 | * `config.yml`: this is a simple configuration file which allows you to
 9 |   specify language-specific customisations.
10 | * `template.tex`: this is the main LaTeX file which determines the style of the
11 |   PDF version of the book. Its contents is run through the ERB templating
12 |   language to include language-specific customisations from config.yml.
13 | 


--------------------------------------------------------------------------------
/latex/config.yml:
--------------------------------------------------------------------------------
  1 | default:
  2 |   font: Helvetica
  3 |   bold: "{* Bold}"
  4 |   mono: Andale Mono
  5 |   prechap: "Chapter "
  6 |   postchap: ""
  7 |   presect: "Section "
  8 |   postsect: ""
  9 |   dql: "“"
 10 |   dqr: "”"
 11 |   con: "Contents"
 12 |   fig: "Figure "
 13 |   tab: "Table "
 14 |   indent: "\\qquad"
 15 |   thanks: "This is the PDF file for the Pro Git book contents. It is licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license. I hope you enjoy it, I hope it helps you learn Git, and I hope you'll support Apress and me by purchasing a print copy of the book at Amazon: \\url{http://tinyurl.com/amazonprogit}"
 16 | zh:
 17 |   langrule: "\\XeTeXlinebreakskip=0em plus 0.1em minus 0.01em\n\\XeTeXlinebreakpenalty=0"
 18 |   font: AR PL UMing CN
 19 |   bold: AR PL UKai CN
 20 |   mono: AR PL UKai CN
 21 |   prechap: "第"
 22 |   postchap: "章"
 23 |   presect: ""
 24 |   postsect: "节"
 25 |   con: "目录"
 26 |   fig: "图 "
 27 |   tab: "表 "
 28 |   indent: "文"
 29 | zh-tw:
 30 |   langrule: "\\XeTeXlinebreakskip=0em plus 0.1em minus 0.01em\n\\XeTeXlinebreakpenalty=0"
 31 |   font: AR PL UMing TW
 32 |   bold: AR PL UKai TW
 33 |   mono: AR PL UKai TW
 34 |   prechap: "第"
 35 |   postchap: "章"
 36 |   presect: ""
 37 |   postsect: "節"
 38 |   dql: "『"
 39 |   dqr: "』"
 40 |   con: "目錄"
 41 |   fig: "圖 "
 42 |   tab: "表 "
 43 |   indent: "文"
 44 | ja:
 45 |   langrule: "\\XeTeXlinebreakskip=0em plus 0.1em minus 0.01em\n\\XeTeXlinebreakpenalty=0"
 46 | #  font: Japan
 47 | #  font: Sazanami Mincho
 48 |   font: IPAPMincho
 49 |   bold: VL PGothic
 50 | #  bold: Sazanami Gothic
 51 | #  bold: IPAPGothic
 52 |   mono: VL Gothic
 53 |   prechap: "第"
 54 |   postchap: "章"
 55 |   presect: ""
 56 |   postsect: "節"
 57 |   dql: "『"
 58 |   dqr: "』"
 59 |   con: "目次"
 60 |   fig: "図"
 61 |   tab: "表"
 62 |   indent: "あ"
 63 | ru:
 64 |   prechap: "Глава "
 65 |   presect: "Раздел "
 66 |   con: "Содержание"
 67 |   fig: "Рисунок "
 68 |   tab: "Таблица "
 69 |   dql: "«"
 70 |   dqr: "»"
 71 | cs:
 72 |   prechap: "Kapitola "
 73 |   presect: "Oddíl "
 74 |   dql: "„"
 75 |   dqr: "“"
 76 |   fig: "Obrázek "
 77 |   tab: "Tabulka "
 78 | fr:
 79 |   prechap: "Chapitre "
 80 |   presect: "Section "
 81 |   fig: "Figure "
 82 |   tab: "Tableau "
 83 |   font: Linux Libertine
 84 |   mono: Courier New
 85 |   con: "Table des matières"
 86 |   langrule: "\\frenchspacing\\usepackage{fontspec}\n\\fontspec[Ligatures={Common}]{Linux Libertine}\n"
 87 |   thanks: "Ce fichier PDF est la traduction française du livre Pro Git. Il est publié sous license Creative Commons Attribution-Non Commercial-Share Alike 3.0. J'espère que vous l'apprécierez, qu'il vous permettra d'apprendre à utiliser Git et que vous aiderez Apress en achetant le livre original sur Amazon : \\url{http://tinyurl.com/amazonprogit}"
 88 |   dql: "«\\,"
 89 |   dqr: "\\,»"
 90 | mk:
 91 |   fig: "Слика"
 92 |   con: "Содржина"
 93 |   prechap: "Поглавје"
 94 |   presect: "Секција"
 95 |   dql: "„"
 96 |   dqr: "“"
 97 |   tab: "Табела"
 98 | de:
 99 |   langrule: "\\frenchspacing"
100 |   dql: "„"
101 |   dqr: "“"
102 | ko:
103 |   langrule: "\\XeTeXlinebreakskip=0em plus 0.1em minus 0.01em\n\\XeTeXlinebreakpenalty=0"
104 |   font: UnBatang
105 |   bold: UnGraphic
106 |   mono: UnDotum
107 |   prechap: ""
108 |   postchap: "장"
109 |   presect: ""
110 |   postsect: "절"
111 |   con: "목차"
112 |   fig: "그림"
113 |   tab: "표"
114 | by:
115 |   prechap: "Глава "
116 |   presect: "Раздзел "
117 |   con: "Змест"
118 |   fig: "Малюнак "
119 |   tab: "Табліца "
120 | 


--------------------------------------------------------------------------------
/latex/makepdf:
--------------------------------------------------------------------------------
  1 | #!/usr/bin/env ruby
  2 | # -*- coding: utf-8 -*-
  3 | require 'fileutils'
  4 | require 'open3'
  5 | require 'erb'
  6 | require 'yaml'
  7 | 
  8 | include FileUtils, Open3
  9 | alias :pipe :popen3
 10 | 
 11 | $here = File.expand_path(File.dirname(__FILE__))
 12 | $root = File.join($here, '..')
 13 | $outDir = File.join($root, 'pdf')
 14 | 
 15 | def figures(&block)
 16 | 	begin
 17 | 		Dir["#$root/figures/18333*.png"].each do |file|
 18 | 			cp(file, file.sub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
 19 | 		end
 20 | 		block.call
 21 | 	ensure
 22 | 		Dir["#$root/figures/18333*.png"].each do |file|
 23 | 			rm(file.gsub(/18333fig0(\d)0?(\d+)\-tn/, '\1.\2'))
 24 | 		end
 25 | 	end
 26 | end
 27 | 
 28 | def usage
 29 | 	puts <'
 66 | 		s /(\n\n)\t(http:\/\/[A-Za-z0-9\/\%\&\=\-\_\\\.]+)\n([^\t]|\t\n)/, '\1<\2>\1'
 67 | 
 68 | 		# Process figures
 69 | 		s /Insert\s18333fig\d+\.png\s*\n.*?\d{1,2}-\d{1,2}\. (.*)/, 'FIG: \1'
 70 | 	end
 71 | end
 72 | 
 73 | def post_pandoc(string, config)
 74 | 	replace(string) do
 75 | 		space = /\s/
 76 | 
 77 | 		# Reformat for the book documentclass as opposed to article
 78 | 		s '\section', '\chap'
 79 | 		s '\sub', '\\'
 80 | 		s /SUBSUBSECTION: (.*)/, '\subsubsection{\1}'
 81 | 
 82 | 		# Enable proper cross-reference
 83 | 		s /#{config['fig'].gsub(space, '\s')}\s*(\d+)\-\-(\d+)/, '\imgref{\1.\2}'
 84 | 		s /#{config['tab'].gsub(space, '\s')}\s*(\d+)\-\-(\d+)/, '\tabref{\1.\2}'
 85 | 		s /#{config['prechap'].gsub(space, '\s')}\s*(\d+)(\s*)#{config['postchap'].gsub(space, '\s')}/, '\chapref{\1}\2'
 86 | 
 87 | 		# Miscellaneous fixes
 88 | 		s /FIG: (.*)/, '\img{\1}'
 89 | 		s '\begin{enumerate}[1.]', '\begin{enumerate}'
 90 | 		s /(\w)--(\w)/, '\1-\2'
 91 | 		s /``(.*?)''/, "#{config['dql']}\\1#{config['dqr']}"
 92 | 
 93 | 		# Typeset the maths in the book with TeX
 94 | 		s '\verb!p = (n(n-1)/2) * (1/2^160))!', '$p = \frac{n(n-1)}{2} \times \frac{1}{2^{160}}$)'
 95 | 		s '2\^{}80', '$2^{80}$'
 96 | 		s /\sx\s10\\\^\{\}(\d+)/, '\e{\1}'
 97 | 
 98 | 		# Convert inline-verbatims into \texttt (which is able to wrap)
 99 | 		s /\\verb(\W)(.*?)\1/ do
100 | 			"{\\texttt{#{verbatim_sanitize($2)}}}"
101 | 		end
102 | 
103 | 		# Ensure monospaced stuff is in a smaller font
104 | 		s /(\\verb(\W).*?\2)/, '{\footnotesize\1}'
105 | 		s /(\\begin\{verbatim\}.*?\\end\{verbatim\})/m, '{\footnotesize\1}'
106 | 
107 | 		# Shaded verbatim block
108 | 		s /(\\begin\{verbatim\}.*?\\end\{verbatim\})/m, '\begin{shaded}\1\end{shaded}'
109 | 	end
110 | end
111 | 
112 | ARGV.delete_if{|arg| $DEBUG = true if arg == '-d' or arg == '--debug'}
113 | languages = ARGV.select{|arg| File.directory?("#$root/#{arg}")}
114 | usage if languages.empty?
115 | 
116 | $config = YAML.load_file("#$here/config.yml")
117 | template = ERB.new(File.read("#$here/template.tex"))
118 | 
119 | missing = ['pandoc', 'xelatex'].reject{|command| command_exists?(command)}
120 | unless missing.empty?
121 | 	puts "Missing dependencies: #{missing.join(', ')}."
122 | 	puts "Install these and try again."
123 | 	exit
124 | end
125 | 
126 | figures do
127 | 	languages.each do |lang|
128 | 		config = $config['default'].merge($config[lang]) rescue $config['default']
129 | 
130 | 		puts "#{lang}:"
131 | 		markdown = Dir["#$root/#{lang}/*/*.markdown"].sort.map do |file|
132 | 			File.read(file)
133 | 		end.join("\n\n")
134 | 
135 | 		print "\tParsing markdown... "
136 | 		latex = pipe('pandoc -p --no-wrap -f markdown -t latex') do |stdin, stdout|
137 | 			stdin.write(pre_pandoc(markdown, config))
138 | 			stdin.close
139 | 			post_pandoc(stdout.read, config)
140 | 		end
141 | 		puts "done"
142 | 
143 | 		print "\tCreating main.tex for #{lang}... "
144 | 		dir = "#$here/#{lang}"
145 | 		mkdir_p(dir)
146 | 		File.open("#{dir}/main.tex", 'w') do |file|
147 | 			file.write(template.result(binding))
148 | 		end
149 | 		puts "done"
150 | 
151 | 		abort = false
152 | 
153 | 		puts "\tRunning XeTeX:"
154 | 		cd($root)
155 | 		3.times do |i|
156 | 			print "\t\tPass #{i + 1}... "
157 | 			pipe("xelatex -output-directory='#{dir}' '#{dir}/main.tex' 2>&1") do |_, stdout|
158 | 				unless $DEBUG
159 | 					if ~ /^!\s/
160 | 						puts "failed with:\n\t\t\t#{$_.strip}"
161 | 						puts "\tConsider running this again with --debug."
162 | 						abort = true
163 | 					end while stdout.gets and not abort
164 | 				else
165 | 					STDERR.print while stdout.gets rescue abort = true
166 | 				end
167 | 			end
168 | 			break if abort
169 | 			puts "done"
170 | 		end
171 | 
172 | 		unless abort
173 | 			print "\tMoving output to progit.#{lang}.pdf... "
174 |                         mv("#{dir}/main.pdf", "#$root/progit.#{lang}.pdf")
175 | 			puts "done"
176 | 		end
177 | 	end
178 | end
179 | 


--------------------------------------------------------------------------------
/latex/template.tex:
--------------------------------------------------------------------------------
  1 | \documentclass[a4paper]{book}
  2 | \usepackage[
  3 | 	%urlbordercolor = {1 1 1},
  4 | 	%linkbordercolor = {1 1 1},
  5 | 	%citebordercolor = {1 1 1},
  6 | 	urlcolor = blue,
  7 | 	colorlinks = true,
  8 | 	citecolor = black,
  9 | 	linkcolor = black]{hyperref}
 10 | \usepackage{graphicx}
 11 | \usepackage{xltxtra}
 12 | \usepackage{fancyhdr}
 13 | \usepackage{booktabs}
 14 | \usepackage{indentfirst}
 15 | \usepackage{framed,color}
 16 | \usepackage{array}
 17 | \usepackage[font=small,format=plain,labelfont=bf,up,textfont=it,up]{caption}
 18 | 
 19 | \definecolor{shadecolor}{gray}{0.90}
 20 | 
 21 | \setromanfont[Mapping=tex-text,Bold=<%= config['bold'] %>]{<%= config['font'] %>}
 22 | \setmonofont{<%= config['mono'] %>}
 23 | 
 24 | \XeTeXlinebreaklocale{<%= lang %>}
 25 | <%= config['langrule'] %>
 26 | 
 27 | \settowidth{\parindent}{<%= config['indent'] %>}
 28 | 
 29 | \title{Pro Git}
 30 | \author{Scott Chacon}
 31 | 
 32 | \makeatletter
 33 | \let\savedauthor=\@author
 34 | \let\savedtitle=\@title
 35 | \def\imgwidth{.6\linewidth}
 36 | \def\maxwidth{\ifdim\Gin@nat@width>\imgwidth\imgwidth
 37 | \else\Gin@nat@width\fi}
 38 | \makeatother
 39 | 
 40 | \title{\textbf{\savedtitle}}
 41 | \author{\textbf{\savedauthor}\thanks{<%= config['thanks'] %>}}
 42 | \def\w3cdtfymd{\the\year-\ifnum\month<10 0\fi\the\month-\ifnum\day<10 0\fi\the\day}
 43 | \date{\w3cdtfymd}
 44 | \renewcommand{\thefootnote}{\fnsymbol{footnote}}
 45 | 
 46 | \newcommand{\PreserveBackslash}[1]{\let\temp=\\#1\let\\=\temp}
 47 | \let\PBS=\PreserveBackslash
 48 | \makeatletter
 49 |   \setlength\headheight{12\p@}
 50 |   \setlength\headsep   {.25in}
 51 |   \setlength\topskip   {10\p@}
 52 |   \setlength\footskip{.35in}
 53 |   \setlength\textwidth{400\p@}
 54 |   
 55 |   \setlength\@tempdima{\paperheight}
 56 |   \addtolength\@tempdima{-2in}
 57 |   \divide\@tempdima\baselineskip
 58 |   \@tempcnta=\@tempdima
 59 |   \setlength\textheight{\@tempcnta\baselineskip}
 60 |   \addtolength\textheight{\topskip}
 61 |   
 62 |   \setlength\@tempdima        {\paperwidth}
 63 |   \addtolength\@tempdima      {-\textwidth}
 64 |   \setlength\oddsidemargin    {\paperwidth}
 65 |   \addtolength\oddsidemargin  {-2.35in}
 66 |   \addtolength\oddsidemargin  {-\textwidth}
 67 |   \setlength\marginparwidth   {0pt}
 68 |   \@settopoint\oddsidemargin
 69 |   \@settopoint\marginparwidth
 70 |   \setlength\evensidemargin  {\paperwidth}
 71 |   \addtolength\evensidemargin{-2.35in}
 72 |   \addtolength\evensidemargin{-\textwidth}
 73 |   \@settopoint\evensidemargin
 74 |   
 75 |   \setlength\topmargin{\paperheight}
 76 |   \addtolength\topmargin{-2in}
 77 |   \addtolength\topmargin{-\headheight}
 78 |   \addtolength\topmargin{-\headsep}
 79 |   \addtolength\topmargin{-\textheight}
 80 |   \addtolength\topmargin{-\footskip}     % this might be wrong!
 81 |   \addtolength\topmargin{-.5\topmargin}
 82 |   \@settopoint\topmargin
 83 | \makeatother
 84 | 
 85 | \fancypagestyle{plain}{\fancyhf{}\fancyfoot[LE,RO]{\footnotesize\textbf\thepage}}
 86 | \pagestyle{plain}
 87 | 
 88 | \renewcommand{\headrulewidth}{0pt}
 89 | \renewcommand{\footrulewidth}{0pt}
 90 | 
 91 | \newcounter{img}[chapter]
 92 | \renewcommand{\theimg}{\thechapter.\arabic{img}}
 93 | \newcommand{\img}[1]{\begin{figure}[h!]
 94 | 	\refstepcounter{img}
 95 | 	\label{img:\theimg}
 96 | 	\centering\includegraphics[width=\maxwidth]{figures/\theimg.png}
 97 | 	\caption{#1}
 98 | \end{figure}}
 99 | 
100 | \newcounter{tab}[chapter]
101 | \renewcommand{\thetab}{\thechapter.\arabic{tab}}
102 | 
103 | \newcommand{\prechap}{<%= config['prechap'] %>}
104 | \newcommand{\postchap}{<%= config['postchap'] %>}
105 | \newcommand{\presect}{<%= config['presect'] %>}
106 | \newcommand{\postsect}{<%= config['postsect'] %>}
107 | \renewcommand{\chaptermark}[1]{\markboth{\textbf{\prechap \thechapter \postchap}\hspace*{1ex}#1}{}}
108 | \renewcommand{\sectionmark}[1]{\markright{\textbf{\presect \thesection \postsect}\hspace*{1ex}#1}}
109 | \newcommand{\chap}[1]{\newpage\thispagestyle{empty}\chapter{#1}\label{chap:\thechapter}}
110 | \newcommand{\chapref}[1]{\hyperref[chap:#1]{\prechap #1\postchap}}
111 | \newcommand{\imgref}[1]{\hyperref[img:#1]{<%= config['fig'] %>#1}}
112 | \newcommand{\tabref}[1]{\hyperref[tab:#1]{<%= config['tab'] %>#1}}
113 | \newcommand{\e}[1]{$ \times 10^{#1}$}
114 | \renewcommand{\contentsname}{<%= config['con'] %>}
115 | \renewcommand{\figurename}{<%= config['fig'] %>}
116 | \renewcommand{\tablename}{<%= config['tab'] %>}
117 | 
118 | \makeatletter
119 | \def\@makechapterhead#1{%
120 |   \vspace*{50\p@}%
121 |   {\parindent \z@ \raggedright \normalfont
122 |     \ifnum \c@secnumdepth >\m@ne
123 |       \if@mainmatter
124 |         \huge\bfseries \prechap \thechapter \postchap
125 |         \par\nobreak
126 |         \vskip 20\p@
127 |       \fi
128 |     \fi
129 |     \interlinepenalty\@M
130 |     \Huge \bfseries #1\par\nobreak
131 |     \vskip 40\p@
132 |   }}
133 | \makeatother
134 | 
135 | \linespread{1.3}
136 | 
137 | \begin{document}
138 | \frontmatter
139 | \maketitle
140 | \thispagestyle{empty}
141 | \setcounter{tocdepth}{4}
142 | \tableofcontents\newpage\thispagestyle{empty}
143 | 
144 | \mainmatter
145 | \fancyhf{}
146 | \fancyhead[LE]{{\small\leftmark}}
147 | \fancyhead[RO]{{\small\rightmark}}
148 | \fancyhead[RE,LO]{{\small\savedauthor\hspace*{1ex}\textbf{\savedtitle}}}
149 | \fancyfoot[LE,RO]{\small\textbf\thepage}
150 | \pagestyle{fancy}
151 | 
152 | <%= latex %>
153 | \end{document}
154 | 


--------------------------------------------------------------------------------
/makeebooks:
--------------------------------------------------------------------------------
 1 | #!/usr/bin/env ruby
 2 | # This script convers markdown book to one of the serveral e-book
 3 | # formats supported with calibre (http://calibre-ebook.com)
 4 | #
 5 | # Samples:
 6 | # 	
 7 | # Build e-book for amazon kindle for english and russian languages
 8 | # 	$ make-ebook en ru
 9 | # or
10 | # 	$ FORMAT=mobi make-ebook en ru
11 | #
12 | # Build e-book in 'epub' format for russian only
13 | # 	$ FORMAT=epub make-ebook ru
14 | 
15 | require 'rubygems'
16 | require 'rdiscount'
17 | require 'ruby-debug'
18 | 
19 | if ARGV.length == 0
20 |   puts "you need to specify at least one language. For example: makeebooks en"
21 |   exit
22 | end
23 | 
24 | format = ENV['FORMAT'] || 'mobi'
25 | puts "using .#{format} (you can change it via FORMAT environment variable. try 'mobi' or 'epub')"
26 | 
27 | ARGV.each do |lang|
28 |   puts "convert content for '#{lang}' language"
29 | 
30 |   book_content = %(Pro Git - professional version control)
31 |   dir = File.expand_path(File.join(File.dirname(__FILE__), lang))
32 |   Dir[File.join(dir, '**', '*.markdown')].sort.each do |input|
33 |     puts "processing #{input}"
34 |     content = File.read(input)
35 |     content.gsub!(/Insert\s+(.*)(\.png)\s*\n?\s*Figure\s+(.*)/, '![\3](figures/\1-tn\2 "\3")')
36 |     book_content << RDiscount.new(content).to_html
37 |   end
38 |   book_content << ""
39 | 
40 |   File.open("progit.#{lang}.html", 'w') do |output|
41 |     output.write(book_content)
42 |   end
43 | 
44 |   system('ebook-convert', "progit.#{lang}.html", "progit.#{lang}.#{format}",
45 |          '--cover', 'ebooks/cover.png',
46 |          '--authors', 'Scott Chacon',
47 |          '--comments', "licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license",
48 |          '--level1-toc', '//h:h1', 
49 |          '--level2-toc', '//h:h2', 
50 |          '--level3-toc', '//h:h3',
51 |          '--language', lang)
52 | end
53 | 


--------------------------------------------------------------------------------
/makepdfs:
--------------------------------------------------------------------------------
 1 | #!/bin/bash
 2 | 
 3 | baseDir=`dirname $0`
 4 | outputDir=${baseDir}/pdf
 5 | 
 6 | exclude=('figures' 'figures-dia' 'figures-source' 'latex' 'makepdfs' 'pdf' 'README')
 7 | dirContent=`ls $baseDir`
 8 | argString=""
 9 | 
10 | for dir in $dirContent; do
11 | 	if [ -n $dir ]; then
12 | 		
13 | 		isLang=1
14 | 		for i in ${exclude[@]}; do
15 | 			if [ $i == $dir ]; then
16 | 				isLang=0
17 | 			fi
18 | 		done
19 | 		
20 | 		if [ $isLang -eq 1 ]; then
21 | 			argString="${argString} ${dir}"
22 | 		fi
23 | 	fi
24 | done
25 | 
26 | echo "Will generate pdf for the following languages:"
27 | echo "	"$argString
28 | 
29 | mkdir -p $outputDir
30 | 
31 | echo 
32 | echo "The generation process will start now."
33 | time ${baseDir}/latex/makepdf $argString
34 | 
35 | echo
36 | echo
37 | echo "Done!"
38 | 


--------------------------------------------------------------------------------
/pl/translation-guidelines.txt:
--------------------------------------------------------------------------------
 1 | 
 2 | Here's a list of agreed translation of the main concepts. Every concepts has
 3 | several translations sorted by accuracy. Generally prefer the first
 4 | translations.
 5 | 
 6 | 
 7 | version control system - system kontroli wersji
 8 | 
 9 | revision control - śledzenie plików, śledzenie zmian
10 | 
11 | snapshot - migawka, wersja plików
12 | 
13 | workflow - schemat pracy
14 | 
15 | commit - commit, zatwierdzenie
16 | 
17 | staging area - przechowalnia
18 | 
19 | staged - w przechowalni, śledzony
20 | 


--------------------------------------------------------------------------------
/ru/figures-dia/fig0101.dia:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chunzi/progit/3c464d5779bb8856c7ddb60696def2d98c8ebd57/ru/figures-dia/fig0101.dia


--------------------------------------------------------------------------------
/summary.rb:
--------------------------------------------------------------------------------
 1 | #! /usr/bin/env ruby
 2 | #
 3 | 
 4 | command = ARGV[0]
 5 | exclude = ['figures', 'figures-dia', 'figures-source', 'couchapp', 'latex', 'pdf', 'epub', 'en', 'ebooks']
 6 | 
 7 | data = []
 8 | original_lines=`grep -r -h '^[^[:space:]#]' en/[0]* | grep -v '^Insert'| wc -l`.to_i
 9 | Dir.glob("*").each do |dir|
10 |   if !File.file?(dir) && !exclude.include?(dir)
11 |     lines = `git diff-tree -r -p --diff-filter=M master:en master:#{dir} | grep '^-[^[:space:]#-]' | grep -v '^-Insert' | wc -l`.strip.to_i
12 |     last_commit = `git log -1 --no-merges --format="%ar" #{dir}`.chomp
13 |     authors = ""
14 |     if command == 'authors'
15 |       authors = `git shortlog --no-merges -s -n #{dir}`.chomp
16 |     end
17 |     data << [dir, lines, authors, last_commit]
18 |   end
19 | end
20 | 
21 | d = data.sort { |a, b| b[1] <=> a[1] }
22 | d.each do |dir, lines, authors, last|
23 |   puts "#{dir.ljust(10)} - #{(lines*100)/original_lines}% (#{last})"
24 |   if command == 'authors'
25 |     puts "Authors: #{authors.split("\n").size}"
26 |     puts authors 
27 |     puts
28 |   end
29 | end
30 | 


--------------------------------------------------------------------------------
/th/01-introduction/01-chapter1.markdown:
--------------------------------------------------------------------------------
  1 | # เริ่มต้นใช้งาน #
  2 | 
  3 | ในบทนี้เราจะเริ่มเรียนรู้เกี่ยวกับการใช้งาน Git โดยจะเริ่มตั้งแต่จุดแรกสุดตั้งแต่อะไรคือเครื่องมือจัดการ version control จากนั้นจึงจะเริ่มอธิบายวิธีการติดตั้ง Git และสุดท้ายคือวิธีการตั้งค่าและเริ่มใช้งาน Git  ในช่วงท้ายบทคุณจะเข้าใจว่าทำไม Git ถึงถูกสร้างขึ้นมาและคุณจะได้ประโยชน์อะไรจากมันบ้าง
  4 | 
  5 | ## เกี่ยวกับ Version Control ##
  6 | 
  7 | Version control คืออะไร และทำไมคุณถึงต้องแคร์? Version control คือ ระบบที่จัดเก็บการเปลี่ยนแปลงที่เกิดขึ้นกับไฟล์หนึ่งหรือหลายไฟล์เพื่อที่คุณสามารถเรียกเวอร์ชั่นใดเวอร์ชั่นหนึ่งกลับมาดูเมื่อไรก็ได้  หนังสือเล่มนี้จะยกตัวอย่างจากไฟล์ที่เป็นซอร์สโค้ดของซอฟต์แวร์ แต่ขอให้เข้าใจว่าจริง ๆ แล้วคุณสามารถใช้ version control กับไฟล์ชนิดใดก็ได้
  8 | 
  9 | ถ้าคุณเป็นนักออกแบบกราฟฟิคหรือเว็บดีไซเนอร์และต้องการเก็บทุกเวอร์ชั่นของรูปภาพหรือเลย์เอาต์ (ซึ่งคุณน่าจะอยากเก็บอยู่) การใช้ Version Control System (VCS) เป็นสิ่งที่ชาญฉลาดมาก เพราะมันช่วยให้คุณสามารถย้อนไฟล์บางไฟล์หรือแม้กระทั่งทั้งโปรเจคกลับไปเป็นเวอร์ชั่นเก่าได้ นอกจากนั้นระบบ VCS ยังจะช่วยให้คุณเปรียบเทียบการแก้ไขที่เกิดขึ้นในอดีต ดูว่าใครเป็นคนแก้ไขคนสุดท้ายที่อาจทำให้เกิดปัญหา แก้ไขเมื่อไร ฯลฯ และยังช่วยให้คุณสามารถกู้คืนไฟล์ที่คุณลบหรือทำเสียโดยไม่ตั้งใจได้อย่างง่ายดาย
 10 | 
 11 | ### Version Control Systems แบบ Local ###
 12 | 
 13 | หลาย ๆ คนจัดเก็บประวัติการแก้ไขต่าง ๆ ด้วยมือโดยการคัดลอกไฟล์ไปไว้ในไดเร็คทอรี่ใหม่ (อาจจะเป็นไดเร็คทอรี่ที่มีชื่อเป็นวันเดือนปีและเวลาก็ได้) วิธีนี้เป็นวิธีที่ใช้กันโดยแพร่หลายเพราะว่าทำได้ง่ายแต่ในขณะเดียวกันก็เป็นวิธีที่เกิดข้อผิดพลาดได้ง่ายเช่นกัน ยกตัวอย่างเช่น คุณอาจไม่ทันดูว่าตอนนี้คุณอยู่ในไดเร็คทอรี่ไหนและเผลอเขียนทับไฟล์ที่คุณไม่น่าจะเขียนทับหรือทำการคัดลอกไฟล์ที่คุณไม่น่าจะคัดลอก
 14 | 
 15 | เพื่อที่จะลดปัญหาเหล่านี้ เมื่อนานมาแล้วโปรแกรมเมอร์ได้พัฒนาระบบ VCS ที่ใช้ในเครื่องของตัวเองโดยใช้ฐานข้อมูลง่าย ๆ เพื่อเก็บการแก้ไขทั้งหมดที่เกิดขึ้นกับไฟล์ที่อยู่ภายใต้ revision control (ดูรูป 1-1)
 16 | 
 17 | Insert 18333fig0101.png 
 18 | รูป 1-1. ระบบ version control แบบ local
 19 | 
 20 | หนึ่งในเครื่องมือ VCS ที่ใช้กันมากทั้งในอดีตและปัจจุบันคือระบบที่เรียกว่า rcs  แม้แต่ระบบปฏิบัติการ Mac OS X ก็ยังติดตั้ง rcs ให้เมื่อคุณติดตั้ง Developer Tools  เครื่องมือนี้ทำงานโดยเก็บสิ่งที่เรียกว่า patch set (ซึ่งก็คือผลต่างของไฟล์แต่ละไฟล์) สำหรับการแก้ไขแต่ละครั้งในรูปแบบพิเศษในเครื่อง ทำให้มันสามารถเรียกคืนไฟล์ ณ ช่วงเวลาใดขึ้นมาดูก็ได้โดยการไล่เรียงไปตาม patch ที่มี
 21 | 
 22 | ### ระบบ Version Control Systems แบบรวมศูนย์ ###
 23 | 
 24 | ปัญหาถัดไปที่คนใช้พบก็คือการร่วมมือกันกับนักพัฒนาคนอื่น ๆ เพื่อที่จะแก้ปัญหานี้เครื่องมือใหม่จีงได้ถูกพัฒนาขึ้นมา เรียกว่าระบบ Centralized Version Control Systems (CVCSs) หรือระบบ Version Control Systems แบบรวมศูนย์  ระบบเหล่านี้ เช่น CVS, Subversion และ Perforce มีเซิร์ฟเวอร์กลางที่เก็บไฟล์ทั้งหมดไว้ในที่เดียวและผู้ใช้หลาย ๆ คนสามารถต่อเข้ามาเพื่อดึงไฟล์จากศูนย์กลางนี้ไปแก้ไขได้ ระบบการทำงานแบบรวมศูนย์นี้ได้ถูกนำมาใช้เป็นเวลานานหลายปี (ดูรูป 1-2)
 25 | 
 26 | Insert 18333fig0102.png 
 27 | รูป 1-2. ระบบ version control แบบรวมศูนย์
 28 | 
 29 | การทำงานแบบนี้มีประโยชน์เหนือ local VCS ในหลายด้าน เช่น ทุกคนสามารถรู้ได้ว่าคนอื่นในโปรเจคกำลังทำอะไร ผู้ควบคุมระบบสามารถควบคุมได้อย่างละเอียดว่าใครสามารถแก้ไขอะไรได้บ้าง การจัดการแบบรวมศูนย์ในที่เดียวทำได้ง่ายกว่าการจัดการฐานข้อมูลใน client แต่ละเครื่องเยอะ
 30 | 
 31 | แต่ระบบแบบนี้ก็มีจุดอ่อนเหมือนกัน ตรงที่การรวมศูนย์ทำให้มันเป็นจุดอ่อนจุดเดียวที่จะล่มได้เหมือนกันเพราะทุกอย่างรวมกันอยู่ที่เซิร์ฟเวอร์ที่เดียว ถ้าเซิร์ฟเวอร์นั้นล่มซักชั่วโมงนึง หมายความว่าในชั่วโมงนั้นไม่มีใครสามารถทำงานร่วมกันหรือบันทึกการเปลี่ยนแปลงงานที่กำลังทำอยู่ไปที่เซิร์ฟเวอร์ได้เลย หรือถ้าฮาร์ดดิสก์ของเซิร์ฟเวอร์เกิดเสียขึ้นมาและไม่มีการสำรองข้อมูลเอาไว้ คุณก็จะสูญเสียข้อมูลประวัติและทุกอย่างที่มี จะเหลือก็แค่ก๊อปปี้ของงานบนเครื่องแต่ละเครื่องเท่านั้นเอง
 32 | 
 33 | ### ระบบ Version Control Systems แบบกระจายศูนย์ ###
 34 | 
 35 | นี่คือที่มาของ Distributed Version Control Systems (DVCSs) หรือระบบ VCS แบบกระจายศูนย์  ในระบบแบบนี้ (เช่น Git, Mercurial, Bazaar หรือ Darcs) แต่ละคนไม่เพียงได้ก๊อปปี้ล่าสุดของไฟล์เท่านั้น แต่ได้ทั้งก๊อปปี้ของ repository เลย หมายความว่าถึงแม้ว่าเซิร์ฟเวอร์จะเสีย client ก็ยังสามารถทำงานร่วมกันได้ต่อไป และ repository เหล่านี้ของ client ยังสามารถถูกก๊อปปี้กลับไปที่เซิร์ฟเวอร์เพื่อกูข้อมูลกลับคืนก็ได้ การ checkout แต่ละครั้งคือการทำสำรองข้อมูลทั้งหมดแบบเต็ม ๆ นั่นเอง (ดูรูป 1-3)
 36 | 
 37 | Insert 18333fig0103.png 
 38 | รูป 1-3. ระบบ version control แบบกระจายศูนย์
 39 | 
 40 | นอกจากนั้นระบบเหล่านี้ยังทำงานกับหลาย ๆ repository ได้อย่างดี ทำให้คุณสามารถทำงานกับคนหลายกลุ่มซึ่งทำงานในรูปแบบต่างกันในโปรเจคเดียวกันได้อย่างง่ายดาย เนื่องจากระบบเหล่านี้สนับสนุนการทำงานได้หลากหลายรูปแบบ ซึ่งอาจทำได้ยากในระบบแบบรวมศูนย์
 41 | 
 42 | ## ประวัติย่อของ Git ##
 43 | 
 44 | เช่นเดียวกันกับหลายสิ่งในชีวิตที่ยิ่งใหญ่ Git เริ่มต้นจากส่วนผสมของความคิดริเริ่มที่สั่นคลอนสถานะปัจจุบันเล็กน้อยแต่ทำให้เกิดผลกระทบในวงกว้าง  โปรเจคลีนุกซ์เคอร์เนล (Linux kernel) ถือเป็นซอฟต์แวร์แบบโอเพนซอร์สที่มีขนาดค่อนข้างใหญ่ ในช่วงปี 1991-2002 การพัฒนาเคอร์เนลถูกแชร์กันไปมาผ่าน patch และไฟล์ซอร์สโค้ดที่ถูกบีบอัด จากนั้นในปี 2002 ก็มีการเริ่มนำเครื่องมือ DVCS ที่ไม่ใช่โอเพนซอร์สชื่อ BitKeeper มาใช้งาน
 45 | 
 46 | ในปี 2005 ความสัมพันธ์ระหว่าง community ที่พัฒนาลีนุกซ์เคอร์เนลและบริษัทที่พัฒนา BitKeeper มีอันต้องจบลง และการใช้งานเครื่องมือนี้แบบฟรีก็ถูกยกเลิกไป ทำให้นักพัฒนาทั้งหลาย (โดยเฉพาะอย่างยิ่งไลนัส ทอร์วอลด์ ผู้สร้างลีนุกซ์) ต้องพัฒนาเครื่องมือของตัวเองขึ้นมาจากประสบการณ์ที่่มีอยู่ระหว่างการใช้งาน BitKeeper โดยมีวัตถุประสงค์ดังนี้:
 47 | 
 48 | *	ความเร็ว
 49 | *	ดีไซน์ที่เรียบง่าย
 50 | *	สนับสนุนการทำงานหลายทางพร้อม ๆ กัน (เช่นมี branch การพัฒนาเป็นพัน)
 51 | *	แยกศูนย์
 52 | *	สามารถรองรับโปรเจคขนาดใหญ่อย่างลีนุกซ์เคอร์เนลได้เป็นอย่างดี (ทั้งในแง่ความเร็วและขนาดของข้อมูล)
 53 | 
 54 | ตั้งแต่เริ่มต้นเมื่อปี 2005 Git ได้ถูกทำให้ใช้งานง่ายขึ้นแต่ก็ยังคงความสามารถตามวัตถุประสงค์เดิมเอาไว้ โดยสามารถทำงานได้เร็วเหลือเชื่อ ใช้พื้นที่น้อยสำหรับโปรเจคใหญ่ ๆ และก็มีระบบการ branch ที่สนับสนุนการทำงานหลายทางพร้อม ๆ กัน (ดูบทที่ 3)
 55 | 
 56 | ## Git ขั้นพื้นฐาน ##
 57 | 
 58 | แล้วสรุปสั้น ๆ ได้ว่า Git คืออะไรล่ะ? ส่วนนี้เป็นส่วนสำคัญที่คุณต้องพยายามทำความเข้าใจเพราะถ้าคุณเข้าใจว่า Git คืออะไรและทำงานอย่างไร คุณจะสามารถใช้งาน Git ได้อย่างมีประสิทธิภาพและง่ายดายมาก เวลาคุณเรียนรู้ Git ให้พยายามลืมสิ่งต่าง ๆ ที่คุณอาจจะรู้อยู่แล้วจาก VCS อื่น ๆ เช่น Subversion หรือ Perforce เพราะคุณอาจสับสนคอนเซ็ปต์จากเครื่องมือเหล่านั้นได้ เหตุผลก็เพราะ Git เก็บและมองข้อมูล่างจากระบบอื่น ๆ เป็นอย่างมากถึงแม้ว่าจะทำงานคล้ายกันก็ตาม
 59 | 
 60 | ### เก็บ Snapshot แทนผลต่าง ###
 61 | 
 62 | ความแตกต่างมากที่สุดระหว่าง Git และ VCS อื่น ๆ (เช่น Subversion และผองเพื่อน) คือ วิธีที่ Git มองข้อมูลต่าง ๆ  โดยทั่วไประบบอื่นมักจะเก็บข้อมูลในรูปแบบของการแก้ไขที่เกิดขึ้นกับไฟล์ต่าง ๆ  ระบบเหล่านี้ (เช่น CVS, Subversion, Perforce, Bazaar, ฯลฯ) จะมองข้อมูลในรูปแบบของไฟล์และการแก้ไขต่าง ๆ ที่เกิดขึ้นกับไฟล์แต่ละไฟล์ ดังเช่นในรูปที่ 1-4
 63 | 
 64 | Insert 18333fig0104.png 
 65 | รูปที่ 1-4. ระบบอื่น ๆ มักจะเก็บข้อมูลโดยอิงกับการแก้ไขที่เกิดขึ้นกับไฟล์
 66 | 
 67 | Git ไม่ได้มองและจัดเก็บข้อมูลในลักษณะนี้ แต่จะคิดว่าข้อมูลของมันเป็นเสมือนภาพถ่าย(snapshot)ของระบบไฟล์ขนาดเล็กๆ ทุกครั้งที่มีการ commit หรือบันทึกสถานะของโปรเจคลงใน Git มันจะทำการถ่ายภาพของไฟล์ทั้งหมดในตอนนั้นและบันทึกการอ้างอิงไปยัง snapshot นั้น เพื่อให้การจัดเก็บนั้นมีประสิทธิภาพ ถ้าไฟล์ใดที่ไม่ได้มีการเปลี่ยนแปลง Git ก็จะไม่บันทึกไฟล์นั้นอีกครั้ง เพียงแต่จะทำการเชื่อมโยงไปยังไฟล์เดิมที่เคยถูกบันทึกเอาไว้อยู่แล้ว Git จะมองข้อมูลดังรูปที่ 1-5
 68 | 
 69 | Insert 18333fig0105.png 
 70 | รูปที่ 1-5. Git เก็บข้อมูลเป็น snapshot ของโปรเจค
 71 | 
 72 | นี่คือความแตกต่างที่สำคัญระหว่าง Git กับ VCSs ตัวอื่นๆ มันทำให้ Git ทำได้เกือบทุกด้านของระบบ VCS อื่นๆ ซึ่งส่วนใหญ่ก็คัดลอกมาจากรุ่นก่อนๆ นี่ทำให้ Git เป็นเหมือนกับระบบไฟล์ขนาดเล็กที่มีเครื่องมือ(tools)อันทรงพลังอย่างน่าเหลือเชื่อครอบอยู่ แทนที่จะเป็น VCS แบบทั่วไป เราจะมาสำรวจข้อดีที่คุณจะได้รับจากแนวคิดแบบนี้เมื่อเรากล่าวถึงเรื่อง การแตกสาขา(Git branching) ในบทที่ 3
 73 | 
 74 | ### การทำงานเกือบทุกอย่างเป็นการทำงานในเครื่องตัวเอง ###
 75 | 
 76 | การทำงานโดยส่วนใหญ่ของ Git จะใช้ไฟล์และทรัพยากรในเครื่องของเราเท่านั้น ปกติจะไม่มีข้อมูลใดๆ ที่จำเป็นต้องใช้จากคอมพิวเตอร์เครื่องอื่นๆ ในเน็ตเวิร์ก แต่หากคุณเคยใช้ CVCS อื่นที่การทำงานส่วนใหญ่ต้องใช้ข้อมูลบนเน็ตเวิร์กจำนวนมาก ในแง่นี้ก็จะทำให้คุณรู้สึกมีความสุขกับความเร็วในการทำงานของ Git เพราะว่าคุณจะมีประวัติการเปลี่ยนแปลงทั้งหมดของโปรเจคอยู่ในเครื่องของคุณอยู่แล้วและพร้อมที่จะทำงานได้ทันที
 77 | 
 78 | ตัวอย่างเช่น ถ้าจะดูประวัติย้อนหลังของโปรเจค Git ไม่จำเป็นที่จะต้องไปดึงข้อมูลจากเซิร์ฟเวอร์แล้วจึงแสดงผลให้คุณได้ มันแค่อ่านโดยตรงจากฐานข้อมูลในเครื่องของคุณ หมายความว่าคุณสามารที่จะดูประวัติของโปรเจคได้ทันที หากคุณจะดูความเปลี่ยนแปลงของไฟล์ในรุ่นปัจจุบันกับเมื่อหนึ่งเดือนที่แล้ว Git ก็สามารถค้นหาไฟล์เมื่อเดือนก่อนในเครื่องของเราแล้วทำการคำนวณความแตกต่าง แทนที่จะถามเครื่องเซิร์ฟเวอร์ให้ดึงไฟล์เก่ามาให้
 79 | 
 80 | ซึ่งก็มีโอกาสน้อยมากที่คุณไม่สามารถทำงานได้ถ้าหากออฟไลน์อยู่ หากคุณต้องเดินทางอยู่บนเครื่องหรือบนรถไฟและอยากจะทำงานสักหน่อย คุณก็สามารถ commit ได้อย่างมีความสุขจนกว่าจะเชื่อมต่อเน็ตเวิร์กได้แล้วอัพโหลด หากที่บ้านของคุณมีปัญหาเรื่องเน็ตเวิร์กคุณก็ยังคงทำงานได้ ถ้าเป็นระบบอื่นทำแบบนี้ไม่ได้แน่ และจะทำอะไรแทบจะไม่ได้เลยหากคุณเชื่อมต่อไปยังเซิร์ฟเวอร์ไม่ได้ ยิ่งในโปรแกรม Subversion และ CVS คุณสามารถแก้ไขไฟล์ต่างๆ ได้แต่จะไม่สามารถ commit ได้เพราะฐานข้อมูลมันออฟไล์อยู่ นี่อาจจะไม่ใช้เรื่องใหญ่อะไรแต่ก็ได้แต่คุณจะแปลกใจในความสามารถนี้ที่ Git ทำได้
 81 | 
 82 | ### Git มีความเที่ยงตรง ###
 83 | 
 84 | ทุกอย่างที่ Git ทำการบันทึกเอาไว้จะถูกทำการ Checksum แล้วนำมาใช้เป็นตัวอ้างอิง นั่นทำให้ไม่มีทางที่เราจะแก้ไขข้อมูลของไฟล์และไดเร็กทอรี่ใดโดยที่ Git จะไม่รู้ ซึ่งฟังก์ชันนี้จะอยู่ในระดับล่างและเป็นหลักการของ Git คุณจะไม่มีทางที่จะทำข้อมูลสูญหายระหว่างการโยกย้ายหรือรับไฟล์ที่เสียหายโดย Git จะสามารถตรวจพบได้
 85 | 
 86 | กลไกที่ Git ใช้ในการทำ Checksum คือการแฮช(hash)แบบ SHA-1 ซึ่งผลลัพธ์จะได้ออกมาเป็นตัวอักษร 40 ตัวที่แทนเลขฐานสิบหก(0-9 และ a-f)จากการคำนวณเนื้อหาในไฟล์หรือโครงสร้างของไดเร็กทอรี่ของ Git ซึ่ง SHA-1 มีลักษณะดังนี้
 87 | 
 88 | 	24b9da6552252987aa493b52f8696cd6d3b00373
 89 | 
 90 | คุณจะเห็นว่าผลของการแฮช(hash)เหล่านี้อยู่ในทุกที่ใน Git เพราะจะถูกใช้บ่อยครั้ง ซึ่งจริงๆแล้ว Git ไม่ได้เก็บบันทึกข้อมูลทุกอย่างตามชื่อไฟล์แต่เก็บในฐานข้อมูลของ Git แล้วสามารถอ้างถึงด้วยค่าแฮช(hash)ของข้อมูลของไฟล์
 91 | 
 92 | ### Git เพียงแต่เพิ่มข้อมูล ###
 93 | 
 94 | เมื่อคุณกระทำอะไรสักอย่างใน Git เนื้อหาเกือบทั้งหมดนั้นก็จะถูกเพิ่มเข้าไปในฐานข้อมูลของ Git เท่านั้น มันเป็นเรื่องยากมากๆ ที่เราจะใช้ระบบที่ทำอะไรลงไปแล้วไม่สามารถย้อนคืนกลับมาได้หรือลบแล้วลบเลย เช่นเดียวกันกับ VCS ตัวอื่นๆ คุณสามารถสูญเสียข้อมูลหรือแก้ไขผิดพลาดได้โดยที่ยังไม่ทันได้ commit แต่ถ้าคุณ commit ลงใน snapshot ของ Git แล้วมันก็ยากที่จะสูญหายได้โดยเฉพาะอย่างยิ่งถ้าคุณทำการผลัก(push)ฐานข้อมูลของคุณไปไว้ที่อื่นๆ
 95 | 
 96 | สิ่งนี้ทำให้การใช้ Git ได้อย่างมีความสุข เพราะเรารู้ว่าเราสามารถทำการทดลองได้โดยที่ไม่มีอันตรายร้ายแรง เราจะดูเนื้อหาลึกๆว่า Git จัดเก็บข้อมูลอย่างไร และเราสามารถกู้ข้อมูลที่สูญหายไปได้อย่างไร ในบทที่ 9
 97 | 
 98 | ### สามสถานะ ###
 99 | 
100 | ทีนี้เราต้องให้ความสนใจหน่อย เพราะนี่คือสิ่งสำคัญของ Git ที่จะต้องจำให้ได้ ถ้าคุณต้องการจะศึกษาส่วนอื่นๆต่อไปของ Git อย่างราบรื่น ไฟล์ของคุณใน Git จะมีอยู่ 3 สถานะ คือ ยืนยันแล้ว(committed), ถูกแก้ไข(modified) และ อยู่ในขั้นตอน(staged) ซึ่ง Committed หมายถึงข้อมูลที่ถูกบันทึกเรียบร้อยแล้วในฐานข้อมูลในเครื่องของคุณ  Modified หมายถึงไฟล์ของคุณได้ถูกแก้ไขแล้วแต่ยังไม่ได้ยืนยัน(commit)ลงในฐานข้อมูลของคุณ Staged หมายถึงคุณได้ทำเครื่องหมายไว้ที่ไฟล์ที่ถูกแก้ไขในเวอร์ชันปัจจุบันเพื่อที่จะรอการ commit ใน snapshot ถัดไป
101 | 
102 | นี่ทำให้โปรเจคที่ใช้ Git มี 3 ส่วน คือ the Git directory, working directory, และ staging area.
103 | 
104 | Insert 18333fig0106.png 
105 | Figure 1-6. Working directory, staging area, และ git directory.
106 | 
107 | Git directory เป็นที่ที่ Git ใช้เก็บ metadata และออปเจ็คของฐานข้อมูลของโปรเจคของคุณ นี่คือส่วนสำคัญที่สุดของ Git และเป็นส่วนที่จะถูกคัดลอกมาเมื่อคุณทำการโคลน(clone)คลังข้อมูลจากคอมพิวเตอร์เครื่องอื่น
108 | 
109 | working directory เป็นเวอร์ชันนึงของไฟล์ในโปรเจคที่ถูกดึงออกมาจากฐานข้อมูลที่ถูกบีบอัดไว้ใน Git directory แล้วเก็บไว้ในดิสก์เพื่อให้คุณนำไปใช้หรือเอามาแก้ไข
110 | 
111 | staging area เป็นไฟล์ธรรมดาไฟล์นึง โดยทั่วไปก็อยู่ใน Git directory ของคุณ ซึ่งเก็บข้อมูลส่วนที่คุณจะทำการ commit ในครั้งถัดไป บางครั้งก็เรียกว่าดัชนี(index) แต่ปกติก็จะเรียกว่า staging area
112 | 
113 | กระบวนการขั้นตอนพื้นฐานของ Git มีลักษณะดังนี้
114 | 
115 | 1.	คุณทำการแก้ไขไฟล์ใน working directory ของคุณ
116 | 2.	แล้วทำการ  stage ไฟล์เหล่านั้นเพื่อให้มีการใส่ snapshot ลงไปใน staging area ของคุณ
117 | 3.	ทำการยืนยัน(commit)ซึ่งนำไฟล์ที่อยู่ใน staging area ไปเก็บอย่างถาวรใน Git directory
118 | 
119 | เมื่อไฟล์อยู่ใน Git directory มันจะถือว่าเป็นสถานะ committed ถ้าไฟล์ถูกแก้ไขแล้วถูกเพิ่มลงใน staging area สถานะจะเป็น staged และถ้าไฟล์ถูกแก้ไขแล้วหลังถูกดึงออกมาแต่ไม่ได้เป็นสถานะ staged ก็จะเป็นสถานะ modified ในบทที่ 2 คุณจะได้เรียนรู้เกี่ยวกับสถานะมากกว่านี้และวิธีการที่คุณสามารถใช้ประโยชน์จากสถานะเหล่านี้หรือการข้ามสถานะ staged ได้อย่างไร
120 | 
121 | ## การติดตั้ง Git ##
122 | 
123 | ก่อนที่จะใช้งานคุณคงต้องติดตั้ง Git ก่อน โดยคุณสามารถทำได้หลายวิธี วิธีหลักสองวิธีคือติดตั้งจากซอร์สโค้ดหรือติดตั้งจากแพคเกจที่มีอยู่แล้วสำหรับระบบปฏิบัติการของคุณ
124 | 
125 | ### ติดตั้งจากซอร์สโค้ด ###
126 | 
127 | ถ้าเป็นไปได้เราขอแนะนำให้คุณติดตั้ง Git โดยการคอมไพล์โปรแกรมจากซอร์สโค้ด เพราะคุณจะได้ใช้เวอร์ชั่นล่าสุดซึ่งมักจะมาพร้อมกับการปรับปรุงอยู่เสมอ อีกเหตุผลหนึ่งก็คือแพคเกจที่มากับลีนุกซ์หลายรุ่นเป็นแพคเกจเวอร์ชั่นเก่ามาก ถ้าคุณไม่ได้ใช้ลีนุกซ์รุ่นล่าสุดหรือใช้ backport การติดตั้งจากซอร์สโค้ดน่าจะเป็นทางเลือกที่ดีที่สุด
128 | 
129 | ก่อนอื่นคุณต้องเตรียม library ที่จำเป็นเสียก่อน คือ curl, zlib, openssl, expat และ libiconv โดยคุณสามารถใช้ yum (ถ้าคุณใช้ Fedora) หรือ apt-get (ถ้าคุณใช้ระบบแบบ Debian) เพื่อติดตั้ง:
130 | 
131 | 	$ yum install curl-devel expat-devel gettext-devel \
132 | 	  openssl-devel zlib-devel
133 | 
134 | 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
135 | 	  libz-dev
136 | 
137 | หลังจากที่ติดตั้งโปรแกรมที่จำเป็นแล้วก็ถึงเวลาดาวน์โหลดเวอร์ชั่นล่าสุดของ Git โดยใช้คำสั่ง:	
138 | 
139 | 	http://git-scm.com/download
140 | 	
141 | จากนั้นก็คอมไพล์และติดตั้ง:
142 | 
143 | 	$ tar -zxf git-1.6.0.5.tar.gz
144 | 	$ cd git-1.6.0.5
145 | 	$ make prefix=/usr/local all
146 | 	$ sudo make prefix=/usr/local install
147 | 
148 | หลังจากติดตั้งเรียบร้อยคุณสามารถดึงซอร์สโค้ดของ Git มาเพื่ออัดเกรดได้โดยใช้ตัวโปรแกรม Git เอง:
149 | 
150 | 	$ git clone git://git.kernel.org/pub/scm/git/git.git
151 | 	
152 | ### การติดตั้งบนลีนุกซ์ ###
153 | 
154 | ถ้าคุณต้องการติดตั้ง Git บนลีนุกซ์โดยใช้แพคเกจสำเร็จรูป คุณสามารถใช้ระบบจัดการแพคเกจที่มากับระบบปฏิบัติการของคุณได้เลย เช่น ถ้าคุณใช้ Fedora คุณสามารถติดตั้งผ่าน yum โดยใช้คำสั่ง:
155 | 
156 | 	$ yum install git-core
157 | 
158 | หรือถ้าคุณใช้ระบบแบบ Debian อย่าง Ubuntu คุณสามารถติดตั้งผ่าน apt-get ได้:
159 | 
160 | 	$ apt-get install git-core
161 | 
162 | ### การติดตั้งบนแมค ###
163 | 
164 | 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):
165 | 
166 | 	http://code.google.com/p/git-osx-installer
167 | 
168 | Insert 18333fig0107.png 
169 | Figure 1-7. Git OS X installer.
170 | 
171 | The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
172 | 
173 | 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
174 | 
175 | 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).
176 | 
177 | ### Installing on Windows ###
178 | 
179 | 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:
180 | 
181 | 	http://code.google.com/p/msysgit
182 | 
183 | 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.
184 | 
185 | ## First-Time Git Setup ##
186 | 
187 | 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.
188 | 
189 | 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:
190 | 
191 | *	`/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. 
192 | *	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. 
193 | *	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`.
194 | 
195 | 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.
196 | 
197 | ### Your Identity ###
198 | 
199 | 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:
200 | 
201 | 	$ git config --global user.name "John Doe"
202 | 	$ git config --global user.email johndoe@example.com
203 | 
204 | 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.
205 | 
206 | ### Your Editor ###
207 | 
208 | 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:
209 | 
210 | 	$ git config --global core.editor emacs
211 | 	
212 | ### Your Diff Tool ###
213 | 
214 | 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:
215 | 
216 | 	$ git config --global merge.tool vimdiff
217 | 
218 | 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.
219 | 
220 | ### Checking Your Settings ###
221 | 
222 | 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:
223 | 
224 | 	$ git config --list
225 | 	user.name=Scott Chacon
226 | 	user.email=schacon@gmail.com
227 | 	color.status=auto
228 | 	color.branch=auto
229 | 	color.interactive=auto
230 | 	color.diff=auto
231 | 	...
232 | 
233 | 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.
234 | 
235 | You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
236 | 
237 | 	$ git config user.name
238 | 	Scott Chacon
239 | 
240 | ## Getting Help ##
241 | 
242 | 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:
243 | 
244 | 	$ git help 
245 | 	$ git  --help
246 | 	$ man git-
247 | 
248 | For example, you can get the manpage help for the config command by running
249 | 
250 | 	$ git help config
251 | 
252 | These commands are nice because you can access them anywhere, even offline.
253 | 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.
254 | 
255 | ## สรุป ##
256 | 
257 | 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.
258 | 


--------------------------------------------------------------------------------
/th/README:
--------------------------------------------------------------------------------
 1 | เนื้อหาหนังสือ Pro Git
 2 | =====================
 3 | 
 4 | นี่คือซอร์สโค้ดของเนื้อหาในหนังสือ Pro Git ซึ่งอยู่ภายใต้สิทธิบัตรแบบ
 5 | Creative Commons Attribution-Non Commercial-Share Alike 3.0  ผู้เขียนหวังว่า
 6 | คุณจะชอบเนื้อหาเหล่านี้ และหวังว่าหนังสือเล่มนี้จะช่วยให้คุณเรียนรู้
 7 | เกี่ยวกับ Git ได้ไม่มากก็น้อย สุดท้ายนี้ผมหวังว่าคุณจะสนับสนุน Apress
 8 | และตัวผู้เขียนโดยการซื้อหนังสือแบบรูปเล่มที่ Amazon นะครับ:
 9 | 
10 | http://tinyurl.com/amazonprogit
11 | 
12 | 
13 | ข้อผิดพลาด
14 | =====================
15 | ถ้าคุณพบข้อผิดพลาดในเนื้อหาที่ต้องมีการแก้ไข กรุณาอีเมล์ผู้เขียนได้ที่
16 | schacon at gmail dot com ครับ
17 | 
18 | 
19 | สำหรับผู้แปล
20 | =====================
21 | ถ้าคุณต้องการแปลหนังสือเล่มนี้ กรุณาสร้างเนื้อหาแปลในไดเร็คทอรี่ย่อยที่เหมาะสม
22 | (เช่น: 'it' สำหรับภาษาอิตาเลียน ฯลฯ) และส่ง pull request ไปที่ผู้เขียน (schacon)
23 | นะครับ จากนั้นผู้เขียนจะนำเนื้อหาที่แปลแล้วขึ้นไปไว้ที่ progit.org
24 | 


--------------------------------------------------------------------------------
/zh-tw/01-introduction/01-chapter1.markdown:
--------------------------------------------------------------------------------
  1 | # 開始 #
  2 | 
  3 | 
  4 | 本章介紹Git的相關知識。 先從講解一些版本控制工具的背景知識開始，然後試著在讀者的系統將Git跑起來，最後則是設定它。 本在章結束，讀者應瞭解為什麼Git如 此流行、為什麼讀者應該利用它、以及完成使用它的準備工作。
  5 | 
  6 | ## 關於版本控制 ##
  7 | 
  8 | 
  9 | 什麼是版本控制？ 以及為什麼讀者會在意它？ 版本控制是一個能夠記錄一個或一組檔案在某一段時間的變更，使得讀者以後能取回特定版本的系統。 在本書的範例中，讀者會學到如何對軟體的原始碼做版本控制。 即使實際上讀者幾乎可以針對電腦上任意型態的檔案做版本控制。
 10 | 
 11 | 
 12 | 若讀者是繪圖或網頁設計師且想要記錄每一版影像或版面配置（這也通常是讀者想要做的），採用版本控制系統（VCS）做這件事是非常明智的。 它允許讀者將檔案復原到原本的狀態、將整個專案復原到先前的狀態、比對某一段時間的修改、查看最後是誰在哪個時間點做了錯誤的修改導致問題發生，等。 使用版本控制系統一般也意謂著若讀者做了一些傻事、或者遺失檔案，讀者能很容易的回復。 更進一步，僅需付出很小的代價即可得到這些優點。
 13 | 
 14 | ### 本地端版本控制 ###
 15 | 
 16 | 
 17 | 許多讀者採用複製檔案到其它目錄的方式來做版本控制（若他們夠聰明的話，或許會是有記錄時間戳記的目錄）。 因為它很簡單，這是個很常見的方法；但它也很容易出錯。 讀者很容易就忘記在哪個目錄，並不小心的把錯誤的檔案寫入、或者複製到不想要的檔案。
 18 | 
 19 | 
 20 | 為了解決這問題，設式設計師在很久以前開發了本地端的版本控制系統，具備簡單的資料庫，用來記載檔案的所有變更記錄（參考圖1-1）。
 21 | 
 22 | Insert 18333fig0101.png 
 23 | 圖1－1。 本地端版本控制流程圖。
 24 | 
 25 | 
 26 | 這種版本控制工具中最流行的是RCS，目前仍存在於許多電腦。 即使是流行的Mac OS X作業系統，都會在讀者安裝開發工具時安裝rcs命令。 此工具基本上以特殊的格式記錄修補集合（即檔案從一個版本變更到另一個版本所需資訊），並儲存於磁碟上。 它就可以藉由套用各修補集合産生各時間點的檔案內容。
 27 | 
 28 | ### 集中式版本控制系統 ###
 29 | 
 30 | 
 31 | 接下來人們遇到的主要問題是需要多位其它系統的開發協同作業。 為了解決此問題，集中式版本控制系統被發展出來。 此系統，如：CVS、Subversion及Perforce皆具備單一伺服器，記錄所有版本的檔案，且有多個客戶端從伺服器從伺服器取出檔案。 在多年後，這已經是版本控制系統的標準（參考圖1－2）。
 32 | 
 33 | Insert 18333fig0102.png 
 34 | 圖1－2. 集中式版本控制系統
 35 | 
 36 | 這樣的配置提供了很多優點，特別是相較於本地端的版本控制系統來說。 例如：每個人皆能得知其它人對此專案做了些什麼修改有一定程度的瞭解。 管理員可調整存取權限，限制各使用者能做的事。 而且維護集中式版本控制系統也比維護散落在各使用者端的資料庫來的容易。
 37 | 
 38 | 然而，這樣的配置也有嚴重的缺點。 最明顯的就是無法連上伺服器時。 如果伺服器關閉一個小時，在這段時間中沒有人能進行協同開發的工作或者將變更的部份傳遞給其它使用者。 如果伺服器用來儲存資料庫的硬碟損毀，而且沒有相關的偏份資料。 除了使用者已取到自己的電腦的版本外，所有資訊，包含該專案開發的歷史都會遺失。 本地端版本控制系統也會有同樣的問題，只要使用者將整個專案的開發歷史都放在同一個地方，就有遺失所有資料的風險。
 39 | 
 40 | ### 分散式版本控制系統 ###
 41 | 
 42 | 這就是分散式版本控制系統被引入的原因。 在分散式版本控制系統，諸如：Git、Mercurial、Bazaar、Darcs。 客戶端不只是取出最後一版的檔案，而是複製整個儲存庫。 即使是整個系統賴以運作的電腦損毀，皆可將任何一個客戶端先前複製的資料還原到伺服器。 每一次的取出動作實際上就是完整備份整個儲存庫。（參考圖1-3）
 43 | 
 44 | Insert 18333fig0103.png 
 45 | 圖1-3. 分散式版本控制系統
 46 | 
 47 | 更進一步來說，許多這樣子的系統皆能同時與數個遠端的機器同時運作。 因此讀者能同時與許多不同群組的人們協同開發同一個專案。 這允許讀者設定多種集中式系統做不到的工作流程，如：階層式模式。
 48 | 
 49 | ## Git 的簡史 ##
 50 | 
 51 | 如同許多生命中美好的事物一樣，Git從有一點創意的破壞及激烈的討論中誕生。 Linux kernel 是開放原始碼中相當大的專案。 在 Linux kernel 大部份的維護時間內（1991～2002），修改該軟體的方式通常以多個修補檔及壓縮檔流通。 在2002年，Linux kernel 開始採用名為 BitKeeper 的商業分散式版本控制系統。
 52 | 
 53 | 在 2005年，開發 Linux kernel 的社群與開發 BitKeeper 的商業公司的關係走向決裂，也無法再免費使用該工具。 這告訴了 Linux 社群及 Linux 之父 Linus Torvalds，該是基於使用 BitKeeper 得到的經驗，開發自有的工具的時候。 這個系統必須達成下列目標：
 54 | 
 55 | *	快速
 56 | *	簡潔的設計
 57 | *	完整支援非線性的開發（上千個同時進行的分支）
 58 | *	完全的分散式系統
 59 | *	能夠有效的處理像 Linux kernel 規模的專案（快速及資料大小）
 60 | 
 61 | 自從 2005 年誕生後，Git已相當成熟，也能很容易使手，並保持著最一開始的要求的品質。 它不可思議的快速、處理大型專案非常有效率、也具備相當優秀足以應付非線性開發的分支系統。（參考第三章）
 62 | 
 63 | ## Git 基礎要點 ##
 64 | 
 65 | 那麼，簡單的說，Git是一個什麼樣的系統？ 這一章節是非常的重要的。 若讀者瞭解什麼是Git以及它的基本工作原因，那麼使用垉來就會很輕鬆且有效率。 在學習之前，試著忘記以前所知道的其它版本控制系統，如：Subversion 及 Perforce。 這將會幫助讀者使用此工具時發生不必要的誤會。 Git儲存資料及運作它們的方式遠異於其它系統，即使它們的使用者介面是很相似的。 瞭解這些差異會幫助讀者更準確的使用此工具。
 66 | 
 67 | ### 記錄檔案快照，而不是差異的部份 ###
 68 | 
 69 | Git與其它版本控制系統（包含Subversion以及與它相關的）的差別是如何處理資料的方式。 一般來說，大部份其它系統記錄資訊是一連串檔案更動的內容。 如圖1-4所示。 這些系統（CVS、Subversion、Perforce、Bazaar等等）儲存一組基本的檔案以及隨時間遞增而更動這些檔案的資料。
 70 | 
 71 | Insert 18333fig0104.png 
 72 | 圖1-4. 其它系統傾向儲存每個檔案更動的資料。
 73 | 
 74 | Git並不以此種方式儲存資料。 而是將其視為小型檔案系統的一組快照。 每一次讀者提交更新時、或者儲存目前專案的狀態到Git時。 基本上它為當時的資料做一組快照並記錄參考到該快照的參考點。 為了講求效率，只要檔案沒有變更，Git不會再度儲存該檔案，而是記錄到前一次的相同檔案的連結。 Git的工作方式如圖1-5所示。
 75 | 
 76 | Insert 18333fig0105.png 
 77 | 圖1-5. Git儲存每次專案更新時的快照。
 78 | 
 79 | 這是Git與所有其它版本控制系統最重要的區別。 它完全顛覆傳統版本控制的作法。 這使用Git更像一個上層具備更強大工具的小型的檔案系統，而不只是版本控制系統。 我們將會在第三章介紹分支時，提到採用此種作法的優點。
 80 | 
 81 | ### 大部份的動作皆可在本地端完成 ###
 82 | 
 83 | 大部份Git的動作皆只需要本地端的檔案及資源即可完成。 一般來說並需要到網路上其它電腦提取的資訊。 若讀者使用集中式版本控制系統，大部份的動作皆包含網路延遲的成本。 這項特點讓你覺得Git處理資料的速度飛快。 因為整個專案的歷史皆存在你的硬碟中，大部份的運作看起來幾乎都是馬上完成。
 84 | 
 85 | 例如：瀏覽器專案的歷史，Git不需要到伺服器下載歷史，而是從本地端的磁碟機讀出來並顯示。 這意謂著讀者幾乎馬上就可以看到專案的歷史。 若讀者想瞭解某個檔案一個月前的版本及現在版本的差別，Git可在本地端找出一個月前的檔案並在比對兩者的差異，而不是要求遠端的伺服器執行這項工作，或者從伺服器取回舊版本的檔案並在本地端比對。
 86 | 
 87 | 這意謂著即使讀者已離線，或者切斷VPN連線後，也很少有讀者無法執行的動作。 若讀者在飛機或火車上，並想要做一些工作，讀者在取得可上傳的網路前仍可很快樂的提交更新。 若讀者回到家且無法讓VPN連線程式正常運作，讀者仍然可繼續工作。 在許多其它系統幾乎是無法做這些事或者必須付出很大代價。 以Perforce為例，在無法連到伺服器時讀者做不了多少事。以Subversion及CVS為例，雖然讀者能編輯檔案，但因為資料庫此時是離線的，讀者無法提交更新到資料庫。 這看起來可能還不是什麼大問題，但讀者可能驚訝Git有這麼大的不同。
 88 | 
 89 | ### Git能檢查完整性 ###
 90 | 
 91 | 在Git中所有的物件在儲存前都會被計算查核碼並以查核碼檢索物件。 這意謂著Git不可能不清楚任何檔案或目錄的內容已被更動。 此功能內建在Git底層並整合到它的設計哲學。 Git不可能偵測不出讀者在傳輸或取得有問題的檔案。
 92 | 
 93 | Git用來計算查核碼的機制稱為SHA1雜湊法。 它由40個十六進制的字母組成的字串組成，基於Git的檔案內容或者目錄結構計算。 查核碼看起來如下所示：
 94 | 
 95 | 	24b9da6552252987aa493b52f8696cd6d3b00373
 96 | 
 97 | 讀者會Git中到處都看到雜湊值，因為它到處被使用。 事實上Git以檔案內容的雜湊值定址出放置資料的地方，而不是檔案名稱。
 98 | 
 99 | ### Git 通常只增加資料 ###
100 | 
101 | 當讀者使用Git，幾乎所有的動作只是增加資料到Git的資料庫。 很難藉此讓做出讓系統無法復原或者清除資料的動作。 在任何版本控制系統，讀者有可能會遺失或者搞混尚未提交的更新。 但是在提交快照到Git後，很少會有遺失的情況，特別是讀者定期將資料庫更新到其它儲存庫。
102 | 
103 | 這讓使用Git可輕鬆的像在玩一樣，因為我們知道我們可以進行任何實驗而不會破壞任何東西。 在第九章的“底層細節”中，我們會進一步討論Git如何儲存資料，以及讀者如何復原看似遺失的資料。
104 | 
105 | ### 三種狀態 ###
106 | 
107 | 現在，注意。 若讀者希望接下來的學習過程順利些，這是關於Git的重要且需記住的事項。 Git有三種表達檔案的狀態：已提交、已修改及已暫存。 已提交意謂著資料己安全地存在讀者的本地端資料庫。 己修改代表著讀者已修改檔案但尚未提交到資料庫。 已暫存意謂著讀者標記已修改檔案目前的版本到下一次提供的快照。
108 | 
109 | 這帶領我們到Git專案的三個主要區域：Git目錄、工作目錄及暫存區域。
110 | 
111 | Insert 18333fig0106.png 
112 | 圖1－6. 工作目錄、暫存區域及git目錄。
113 | 
114 | Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這是Git最重要的部份而且它是當讀者從其它電腦複製儲存庫時會複製過來的。
115 | 
116 | 工作目錄是專案被取出的某一個版本。 這些檔案從Git目錄內被壓縮過的資料庫中拉出來並放在磁碟機供讀者使用或修改。
117 | 
118 | 暫存區域是一個單純的檔案，一般來說放在Git目錄，儲存關於下一個提交的資訊。 有時稱為索引，但現在將它稱為暫存區域已開始成為標準。
119 | 
120 | 基本Git工作流程大致如下：
121 | 
122 | 1.	讀者修改工作目錄內的檔案。
123 | 2.	讀者將檔案的快照新增到暫存區域。
124 | 3.	做提交的動作，這會讓存在暫存區域的檔案快照永久的儲存在Git目錄。
125 | 
126 | 在Git目錄內特定版本的檔案被認定為已提交。 若檔案被修改且被增加到暫存區域，稱為被暫存。 若檔案被取出後有被修改，但未被暫存，稱為被修改。 在第二章讀者會學到更多關於這些狀態以及如何利用它們的優點或者整個略過暫存步驟。
127 | 
128 | ## 安裝Git ##
129 | 
130 | 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.
131 | 讓我們開始使用Git。 首先讀者要做的事是安裝Git。 讀者有很多取得它們的方法。 主要的兩種分別是從原始碼安裝或者從讀者使用平台現存的套件安裝。
132 | 
133 | ### 從原始碼安裝 ###
134 | 
135 | 若讀者有能力的話，從原始碼安裝是非常有用的。 因為讀者能取得最新版本。 每一版Git通常都會包含有用的UI改善。 因此取得最新版本通常是最好的，只要讀者覺得編譯軟體的原始碼是很容易的。 許多Linux發行套件通常都是附上非常舊的套件。 除非讀者使用的發行套件非常新或者使用向後相容的移植版本。 從原始碼安裝通常是最好的選擇。
136 | 
137 | 要安裝Git，讀者需要先安裝它需要的程式庫：curl、zlib、openssl、expat及libiconv。 例如：若讀者的系統有yum（如：Fedpra）或apt-get（如：以Debian為基礎的系統），讀者可使用下列任一命令安裝所有需要的程式庫：
138 | 
139 | 	$ yum install curl-devel expat-devel gettext-devel \
140 | 	  openssl-devel zlib-devel
141 | 
142 | 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
143 | 	  libz-dev
144 | 	
145 | 當讀者安裝所有必要的程式庫，讀者可到Git的網站取得最新版本：
146 | 
147 | 	http://git-scm.com/download
148 | 	
149 | 接著，編譯及安裝：
150 | 
151 | 	$ tar -zxf git-1.6.0.5.tar.gz
152 | 	$ cd git-1.6.0.5
153 | 	$ make prefix=/usr/local all
154 | 	$ sudo make prefix=/usr/local install
155 | 
156 | 在這些工作完成後，讀者也可以使用Git取得Git的更新版：
157 | 
158 | 	$ git clone git://git.kernel.org/pub/scm/git/git.git
159 | 	
160 | ### 在Linux系統安裝 ###
161 | 
162 | 若讀者想使用二進位安裝程式安裝Git到Linux，一般來說讀者可經由發行套件提供的套件管理工具完成此工作。 若讀者使用Fedora，可使用yum：
163 | 
164 | 	$ yum install git-core
165 | 
166 | 若讀者在以Debian為基礎的發行套件，如：Ubuntu。 試試apt-get：
167 | 
168 | 	$ apt-get install git-core
169 | 
170 | ### 在Mac系統安裝 ###
171 | 
172 | 有兩種很容易將Git安裝到Mac的方法。 最簡單的是使用圖形化界面的Git安裝程式，可從Google Code下載）圖1－7）：
173 | 
174 | 	http://code.google.com/p/git-osx-installer
175 | 
176 | Insert 18333fig0107.png 
177 | 圖1-7. Git OS X 安裝程式。
178 | 
179 | 藉由MacPorts安裝Git是另一種主要的方法。 若讀者已安裝MacPorts，使用下列命令安裝Git
180 | 
181 | 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
182 | 
183 | 讀者完全不需要安裝所有的額外套件，但讀者可能會想要加上+svn參數，以利於使用Git讀寫Subversion儲存庫（參考第8章）
184 | 
185 | ### 在Windows系統安裝 ###
186 | 
187 | 在Windows系統安裝Git相當的容易。 msysGit專案已提供相當容易安裝的程序。 只要從Google Code網頁下載安裝程式並執行即可：
188 | 
189 | 	http://code.google.com/p/msysgit
190 | 
191 | 在安裝完畢後，讀者同時會有命令列版本（包含SSH客戶端程式）及標準的圖形界面版本。
192 | 
193 | ## 初次設定Git ##
194 | 
195 | 現在讀者的系統已安裝了Git，讀者可能想要做一些客製化的動作。 讀者應只需要做這些工作一次。 這些設定在更新版本時會被保留下來。 讀者可藉由再度執行命令的方式再度修改這些設定。
196 | 
197 | Git附帶名為git config的工具，允許讀者取得及設定組態參數，可用來決定Git外觀及運作。 這些參數可存放在以下三個地方：
198 | 
199 | *	檔案 /etc/gitconfig： 包含給該系統所有使用者的儲存庫使用的數值。 只要讀者傳遞 --system 參數給 git config，它就會讀取或者寫入參數到這個檔案
200 | *	檔案 ~/.gitconfig： 給讀者自己的帳號使用。 傳遞 --global 參數給 git config，它就會讀取或者寫入參數到這個檔案。
201 | *	儲存庫內的設定檔，也就是 .git/config： 僅給所在的儲存庫使用。 每個階級的設定會覆寫上一層的。 因此.git/config內的設定值的優先權高過/etc/config。
202 | 
203 | 在Windows系統，Git在$HOME目錄(對大部份使用者來說是`C:\Documents and Settings\$USER`)內尋找.gitconfig。 它也會尋找/etc/gitconfig，只不過它是相對於Msys根目錄，取決於讀者當初在Windows系統執行Git的安裝程式時安裝的目的地。
204 | 
205 | ### 設定識別資料 ###
206 | 
207 | 讀者安裝Git後首先應該做的事是指定使用者名稱及電子郵件帳號。 這一點非常重要，因為每次Git提交會使用這些資訊，而且提交後不能再被修改：
208 | 
209 | 	$ git config --global user.name "John Doe"
210 | 	$ git config --global user.email johndoe@example.com
211 | 
212 | 再說一次，若讀者有指定 --global 參數，只需要做這工作一次。 因為在此系統，不論Git做任何事都會採用此資訊。 若讀者想指定不同的名字或電子郵件給特定的專案， 只需要在該專案目錄內執行此命令，並確定未加上 --global 參數。
213 | 
214 | ### 指定編輯器 ###
215 | 
216 | 現在讀者的識別資料已設定完畢，讀者可設定預設的文書編輯器，當Git需要讀者輸入訊息時會叫用它。 預設情況下，Git會使用系統預設的編輯器，一般來說是Vi或Vim。 若讀者想指定不同的編輯器，例如：Emacs。可執行下列指令：
217 | 
218 | 	$ git config --global core.editor emacs
219 | 	
220 | ### 指定合併工具 ###
221 | 
222 | 另外一個對讀者來說有用的選項是設定解決合併失敗時，讀者慣用的合併工具。 假設讀者想使用vimdiff：
223 | 
224 | 	$ git config --global merge.tool vimdiff
225 | 
226 | Git能接受kdiff3、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff、ecmerge及opendiff做為合併工具。 讀者可設定自訂的工具。 詳情參考第七章。
227 | 
228 | ### 檢查讀者的設定 ###
229 | 
230 | 若讀者想確認設定值，可使用 git config --list 命令列出所有Git能找到的設定值：
231 | 
232 | 	$ git config --list
233 | 	user.name=Scott Chacon
234 | 	user.email=schacon@gmail.com
235 | 	color.status=auto
236 | 	color.branch=auto
237 | 	color.interactive=auto
238 | 	color.diff=auto
239 | 	...
240 | 
241 | 讀者可能會看到同一個設定名稱出現多次，因為Git從不同的檔案讀到同一個設定名稱（例如：/etc/gitconfig及~/.gitconfig）。 在這情況下，Git會使用最後一個設定名稱的設定值。
242 | 
243 | 使用者也可以下列命令 git config 設定名稱，檢視Git認為該設定名稱的設定值：
244 | 
245 | 	$ git config user.name
246 | 	Scott Chacon
247 | 
248 | ## 取得說明文件 ##
249 | 
250 | 若讀者在使用Git時需要幫助，有三種方法取得任何Git命令的手冊：
251 | 
252 | 	$ git help 命令
253 | 	$ git 命令 --help
254 | 	$ man git-命令
255 | 
256 | 例如：讀者可以下列命令取得config命令的手冊
257 | 
258 | 	$ git help config
259 | 
260 | 這些命令對讀者是很有幫助的，因為讀者可在任意地方取得它們，即使已離線。
261 | 若手冊及這本書不足以幫助讀者，且讀者需要更進一步的協助。 讀者可試著進入Freenode IRC伺服器（irc.freenode.net）的#git或#github頻道。 這些頻道平時都有上百位對Git非常瞭解的高手而且通常樂意協助。
262 | 
263 | ## 總結 ##
264 | 
265 | 目前讀者應該對於Git有一些基本的瞭解，而且知道它與其它集中式版本控制系統的不同，其中有些可能是讀者正在使用的。 讀者的系統現在也應該有一套可動作的Git且已設定好讀者個人的識別資料。 現在正是學習一些Git的基本的操作的好時機。
266 | 


--------------------------------------------------------------------------------
/zh/01-introduction/01-chapter1.markdown:
--------------------------------------------------------------------------------
  1 | # 起步 #
  2 | 
  3 | 本章介绍开始使用 Git 前的相关知识。我们会先了解一些版本控制工具的历史背景，然后试着让 Git 在你的系统上跑起来，直到最后配置好，可以正常开始开发工作。读完本章，你就会明白为什么 Git 会如此流行，为什么你应该立即开始使用它。
  4 | 
  5 | ## 关于版本控制 ##
  6 | 
  7 | 什么是版本控制？我真的需要吗？版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本书所展示的例子中，我们仅对保存着软件源代码的文本文件作版本控制管理，但实际上，你可以对任何类型的文件进行版本控制。
  8 | 
  9 | 如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能）。采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而导致出现怪异问题，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。
 10 | 
 11 | ### 本地版本控制系统 ###
 12 | 
 13 | 许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。
 14 | 
 15 | 为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异（见图 1-1）。
 16 | 
 17 | Insert 18333fig0101.png 
 18 | 图 1-1. 本地版本控制系统
 19 | 
 20 | 其中最流行的一种叫做 rcs，现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录着对应文件修订前后的内容变化。所以，根据每次修订后的补丁，rcs 可以通过不断打补丁，计算出各个版本的文件内容。
 21 | 
 22 | ### 集中化的版本控制系统 ###
 23 | 
 24 | 接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法（见图 1-2）。
 25 | 
 26 | Insert 18333fig0102.png 
 27 | 图 1-2. 集中化的版本控制系统
 28 | 
 29 | 这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
 30 | 
 31 | 事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就还是会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
 32 | 
 33 | ### 分布式版本控制系统 ###
 34 | 
 35 | 于是分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（见图 1-3）。
 36 | 
 37 | Insert 18333fig0103.png 
 38 | 图 1-3. 分布式版本控制系统
 39 | 
 40 | 更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
 41 | 
 42 | ## Git 简史 ##
 43 | 
 44 | 同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的  Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。
 45 | 
 46 | 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：
 47 | 
 48 | * 速度
 49 | * 简单的设计
 50 | * 对非线性开发模式的强力支持（允许上千个并行开发的分支）
 51 | * 完全分布式
 52 | * 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
 53 | 
 54 | 自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统（见第三章），可以应付各种复杂的项目开发需求。
 55 | 
 56 | ## Git 基础 ##
 57 | 
 58 | 那么，简单地说，Git 究竟是怎样的一个系统呢？请注意，接下来的内容非常重要，若是理解了 Git 的思想和基本工作原理，用起来就会知其所以然，游刃有余。在开始学习 Git 的时候，请不要尝试把各种概念和其他版本控制系统（诸如 Subversion 和 Perforce 等）相比拟，否则容易混淆每个操作的实际意义。Git 在保存和处理各种信息的时候，虽然操作起来的命令形式非常相近，但它与其他版本控制系统的做法颇为不同。理解这些差异将有助于你准确地使用 Git 提供的各种工具。
 59 | 
 60 | ### 直接记录快照，而非差异比较 ###
 61 | 
 62 | Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，请看图 1-4。
 63 | 
 64 | Insert 18333fig0104.png 
 65 | 图 1-4. 其他系统在每个版本中记录着各个文件的具体差异
 66 | 
 67 | Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图 1-5 所示。
 68 | 
 69 | Insert 18333fig0105.png 
 70 | 图 1-5. Git 保存每次更新时的文件快照
 71 | 
 72 | 这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路，并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统，但它同时还提供了许多以此为基础的超强工具，而不只是一个简单的 VCS。稍后在第三章讨论 Git 分支管理的时候，我们会再看看这样的设计究竟会带来哪些好处。
 73 | 
 74 | ### 近乎所有操作都是本地执行 ###
 75 | 
 76 | 在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。
 77 | 
 78 | 举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。
 79 | 
 80 | 用 CVCS 的话，没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（译注：默认无法发出命令 `p4 edit file` 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。
 81 | 
 82 | ### 时刻保持数据完整性 ###
 83 | 
 84 | 在保存到 Git 之前，所有数据都要进行内容的校验和（checksum）计算，并将此结果作为数据的唯一标识和索引。换句话说，不可能在你修改了文件或目录之后，Git 一无所知。这项特性作为 Git 的设计哲学，建在整体架构的最底层。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git 都能立即察觉。
 85 | 
 86 | Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是：
 87 | 
 88 | 	24b9da6552252987aa493b52f8696cd6d3b00373
 89 | 
 90 | Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保存在 Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。  
 91 | 
 92 | ### 多数操作仅添加数据 ###
 93 | 
 94 | 常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删除数据，都会使回退或重现历史版本变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些修改的内容，但在 Git 里，一旦提交快照之后就完全不用担心丢失数据，特别是养成定期推送到其他仓库的习惯的话。
 95 | 
 96 | 这种高可靠性令我们的开发工作安心不少，尽管去做各种试验性的尝试好了，再怎样也不会弄丢数据。至于 Git 内部究竟是如何保存和恢复数据的，我们会在第九章讨论 Git 内部原理时再作详述。
 97 | 
 98 | ### 文件的三种状态 ###
 99 | 
100 | 好，现在请注意，接下来要讲的概念非常重要。对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。
101 | 
102 | 由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。
103 | 
104 | Insert 18333fig0106.png 
105 | 图 1-6. 工作目录，暂存区域，以及本地仓库
106 | 
107 | 每个项目都有一个 Git 目录（译注：如果 `git clone` 出来的话，就是其中 `.git` 的目录；如果 `git clone --bare` 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。
108 | 
109 | 从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做工作目录。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。
110 | 
111 | 所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。
112 | 
113 | 基本的 Git 工作流程如下：
114 | 
115 | 1. 在工作目录中修改某些文件。
116 | 2. 对修改后的文件进行快照，然后保存到暂存区域。
117 | 3. 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
118 | 
119 | 所以，我们可以从文件所处的位置来判断状态：如果是 Git 目录中保存着的特定版本文件，就属于已提交状态；如果作了修改并已放入暂存区域，就属于已暂存状态；如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态。到第二章的时候，我们会进一步了解其中细节，并学会如何根据文件状态实施后续操作，以及怎样跳过暂存直接提交。
120 | 
121 | ## 安装 Git ##
122 | 
123 | 是时候动手尝试下 Git 了，不过得先安装好它。有许多种安装方式，主要分为两种，一种是通过编译源代码来安装；另一种是使用为特定平台预编译好的安装包。
124 | 
125 | ### 从源代码安装 ###
126 | 
127 | 若是条件允许，从源代码安装有很多好处，至少可以安装最新的版本。Git 的每个版本都在不断尝试改进用户体验，所以能通过源代码自己编译安装最新版本就再好不过了。有些 Linux 版本自带的安装包更新起来并不及时，所以除非你在用最新的 distro 或者 backports，那么从源代码安装其实该算是最佳选择。
128 | 
129 | Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代码，所以需要先安装这些依赖工具。在有 yum 的系统上（比如 Fedora）或者有 apt-get 的系统上（比如 Debian 体系），可以用下面的命令安装：
130 | 
131 | 	$ yum install curl-devel expat-devel gettext-devel \
132 | 	  openssl-devel zlib-devel
133 | 
134 | 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
135 | 	  libz-dev libssl-dev
136 | 	
137 | 之后，从下面的 Git 官方站点下载最新版本源代码：
138 | 
139 | 	http://git-scm.com/download
140 | 
141 | 然后编译并安装：
142 | 
143 | 	$ tar -zxf git-1.7.2.2.tar.gz
144 | 	$ cd git-1.7.2.2
145 | 	$ make prefix=/usr/local all
146 | 	$ sudo make prefix=/usr/local install
147 | 
148 | 现在已经可以用 `git` 命令了，用 `git` 把 Git 项目仓库克隆到本地，以便日后随时更新：
149 | 
150 | 	$ git clone git://git.kernel.org/pub/scm/git/git.git
151 | 	
152 | ### 在 Linux 上安装 ###
153 | 
154 | 如果要在 Linux 上安装预编译好的 Git 二进制安装包，可以直接用系统提供的包管理工具。在 Fedora 上用 yum 安装：
155 | 
156 | 	$ yum install git-core
157 | 
158 | 在 Ubuntu 这类 Debian 体系的系统上，可以用 apt-get 安装：
159 | 
160 | 	$ apt-get install git-core
161 | 
162 | ### 在 Mac 上安装 ###
163 | 
164 | 在 Mac 上安装 Git 有两种方式。最容易的当属使用图形化的 Git 安装工具，界面如图 1-7，下载地址在：
165 | 
166 | 	http://code.google.com/p/git-osx-installer
167 | 
168 | Insert 18333fig0107.png 
169 | 图 1-7. Git OS X 安装工具
170 | 
171 | 另一种是通过 MacPorts (`http://www.macports.org`) 安装。如果已经装好了 MacPorts，用下面的命令安装 Git：
172 | 
173 | 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
174 | 
175 | 这种方式就不需要再自己安装依赖库了，Macports 会帮你搞定这些麻烦事。一般上面列出的安装选项已经够用，要是你想用 Git 连接 Subversion 的代码仓库，还可以加上 +svn 选项，具体将在第八章作介绍。（译注：还有一种是使用 homebrew（`https://github.com/mxcl/homebrew`）：`brew install git`。）
176 | 
177 | ### 在 Windows 上安装 ###
178 | 
179 | 在 Windows 上安装 Git 同样轻松，有个叫做 msysGit 的项目提供了安装包，可以到 Google Code 的页面上下载 exe 安装文件并运行：
180 | 
181 | 	http://code.google.com/p/msysgit
182 | 
183 | 完成安装之后，就可以使用命令行的 `git` 工具（已经自带了 ssh 客户端）了，另外还有一个图形界面的 Git 项目管理工具。
184 | 
185 | ## 初次运行 Git 前的配置 ##
186 | 
187 | 一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。
188 | 
189 | Git 提供了一个叫做 git config 的工具（译注：实际是 `git-config` 命令，只不过可以通过 `git` 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：
190 | 
191 | * `/etc/gitconfig` 文件：系统中对所有用户都普遍适用的配置。若使用 `git config` 时用 ` --system` 选项，读写的就是这个文件。
192 | * `~/.gitconfig` 文件：用户目录下的配置文件只适用于该用户。若使用 `git config` 时用 ` --global` 选项，读写的就是这个文件。
193 | * 当前项目的 git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。
194 | 
195 | 在 Windows 系统上，Git 会找寻用户主目录下的 `.gitconfig` 文件。主目录即 `$HOME` 变量指定的目录，一般都是 `C:\Documents and Settings\$USER`。此外，Git 还会尝试找寻 `/etc/gitconfig` 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。
196 | 
197 | ### 用户信息 ###
198 | 
199 | 第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：
200 | 
201 | 	$ git config --global user.name "John Doe"
202 | 	$ git config --global user.email johndoe@example.com
203 | 
204 | 如果用了 `--global` 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 `--global` 选项重新配置即可，新的设定保存在当前项目的 `.git/config` 文件里。
205 | 
206 | ### 文本编辑器 ###
207 | 
208 | 接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候，会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器，一般可能会是 Vi 或者 Vim。如果你有其他偏好，比如 Emacs 的话，可以重新设置：
209 | 
210 | 	$ git config --global core.editor emacs
211 | 	
212 | ### 差异分析工具 ###
213 | 
214 | 还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：
215 | 
216 | 	$ git config --global merge.tool vimdiff
217 | 
218 | Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合并工具的输出信息。当然，你也可以指定使用自己开发的工具，具体怎么做可以参阅第七章。
219 | 
220 | ### 查看配置信息 ###
221 | 
222 | 要检查已有的配置信息，可以使用 `git config --list` 命令：
223 | 
224 | 	$ git config --list
225 | 	user.name=Scott Chacon
226 | 	user.email=schacon@gmail.com
227 | 	color.status=auto
228 | 	color.branch=auto
229 | 	color.interactive=auto
230 | 	color.diff=auto
231 | 	...
232 | 
233 | 有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 `/etc/gitconfig` 和 `~/.gitconfig`），不过最终 Git 实际采用的是最后一个。
234 | 
235 | 也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样：
236 | 
237 | 	$ git config user.name
238 | 	Scott Chacon
239 | 
240 | ## 获取帮助 ##
241 | 
242 | 想了解 Git 的各式工具该怎么用，可以阅读它们的使用帮助，方法有三：
243 | 
244 | 	$ git help 
245 | 	$ git  --help
246 | 	$ man git-
247 | 
248 | 比如，要学习 config 命令可以怎么用，运行：
249 | 
250 | 	$ git help config
251 | 
252 | 我们随时都可以浏览这些帮助信息而无需连网。不过，要是你觉得还不够，可以到 Frenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。
253 | 
254 | ## 小结 ##
255 | 
256 | 至此，你该对 Git 有了点基本认识，包括它和以前你使用的 CVCS 之间的差别。现在，在你的系统上应该已经装好了 Git，设置了自己的名字和电邮。接下来让我们继续学习 Git 的基础知识。
257 | 


--------------------------------------------------------------------------------